Jonathan wrote:
> I encountered this problem (actually a related problem,
> not this specific one) while writing some syntax
> colouring code for use in ved, a couple of years ago.
> IIRC it was actually a bug(?) in ved, but for a similar
> reason.
>
> But it's an example of why poplog needs a bug-tracker,
> perhaps by using the bug-tracking mechanism on the
> sourceforge Openpoplog site. I'm sure I would have
> reported it, if the poplog community had (and used)
> an agreed official bug-reporting mechanism.
ISL used to have a process, and a form (of which a relic remains in
HELP BUGFORM).
Since Poplog became available free of charge in 1999 very few bugs have
emerged.
As far as I know all of those reported to pop-forum or to me are
listed here, along with fixes for almost all of them:
http://www.cs.bham.ac.uk/research/poplog/bugfixes/BUGREPORTS
I am now inclined to think that the problem I encountered is not
due to a bug, simply to the cognitive demands imposed by a rich
and flexible programming language!
> As for your specific question, my answer is: I don't know.
>
> (As an aside, I tend not to use nested comments in my
> code, either in C++ or pop11 or whatever, anymore,
> I tend to stick to the EOL style of commenting.
> ENTER gsr/@a/;;; / is actually less effort than inserting
> a /* ... */ pair and makes the comment stand out better.
Most people who think about comments think about code files containing
text (or code) in comments.
In poplog there are many text files which include code examples, and
some of them are designed to be compiled. An example of this tutorial
style is TEACH RC_CONTROL_PANEL, which is part of RCLIB, and can be
found here
http://www.cs.bham.ac.uk/research/poplog/rclib/teach/rc_control_panel
you can compile the file and then give some commands described in the
file.
One of the commands that is commented out and therefore has to be run
explicitly builds a demonstration graphical control panel using
structures and procedures created by compiling the whole file.
Other bits of pop11 not included in the commented out text define
fragments of the panel, or fragments of the specification of the panel,
or procedures used by the panel; or they declare variables modified by
events on the panel. Some of the commented out bits of code are
instructions for manipulating the panel after it has been
constructed.
This sort of style (alternating between comments and code, where
the comments include additional optional bits of code that can be
marked and run) provides quite a nice tutorial style which I and others
have used often.
It would be very clumsy to do entirely using end of line comments
but a suitably programmed editor could make it easier both to
generate the file (eg. handling the comment symbols correctly when
a piece of text is edited and reformatted, and when a user tries
to mark and load a commented out example).
It would be a pity to make any change that made that impossible
or very difficult.
> How many times to you see big comments enclosed in a box
> of asterisks, to make them stand out? In C++ the #ifdef
> mechanism is useful for hiding blocks of code, and is
> better than using comment brackets for that purpose;
> there is a similar mechanism in pop11.
That is an ingenious suggestion. I.e. in addition to the 'official'
comment styles, pop11 supports comments like this using its conditional
compilation syntax:
#_IF false
This is a comment and will not cause syntactic errors
even if it includes
'#_ENDIF'
because the string quotes successfully hide the closing
bracket, unlike '*/' in a normal pop11 comment.
#_ENDIF
What's more, those brackets can even be nested.
Hmm...
Aaron
|