When updating the documentation, Peter N Lewis and I came to the
problem how to describe the Boolean values `True' and `False'.
Peter suggested "true (conforming to reality) and false (different
from reality", but I think "reality" is not a good term here (what
do computer programs have to do with reality, anyway ;-).
Perhaps the only thing that can be said is that there are two
values, true and false, and that one is the opposite of the other.
But they have some certain meanings as …
[View More]conditions in `if' and loops,
and in expressions like `x = 2'.
Does anyone have a useful description without being selfreferential
and without referring to "reality"?
BTW, ISO 10206 contains things like these:
: The Booleantype shall be an ordinaltype. The values
: shall be the enumeration of truth values denoted by the required
: constantidentifiers false and true, such that false is the predecessor
: of true. The ordinal numbers of the truth values denoted by false and
: true shall be the integer values 0 and 1 respectively.
: The operator in shall yield the value true if
: the value of the operand of ordinaltype is a member of the value of the
: settype; otherwise, it shall yield the value false.
: If the Booleanexpression of the ifstatement yields the value true, the
: statement of the ifstatement shall be executed. If the Booleanexpression
: yields the value false, the statement of the ifstatement shall not be
: executed, and the statement of the elsepart, if any, shall be executed.
Frank
--
Frank Heckenbach, frank(a)g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
[View Less]
Some weeks ago, I've installed the user input forms on the GPC web
pages.
Unfortunately, they've not proven too useful yet. The only entries
of the intended kind came from Richard Jackson who suggested the
forms initially ...
Many of the other entries were silly stuff ("Micky Mouse" etc.).
Some mistook the forms for a kind of "guestbook".
The remaining ones were questions or discussion items. While not
useless, they're probably better served by the mailing lists where
more interested people …
[View More]will read them (in contrast to the web pages
where only those who visit the page again will read it, and I guess
many regular users only visit a few pages regularly).
Maybe the text above the form isn't clear enough (but maybe it is,
and people just don't read it; they see a form and just write
whatever they have in mind ...). But as it's now, I don't think the
forms are really useful.
Therefore, unless someone has an idea how to "rescue" them, I'm
afraid they'll be gone in a few days ...
Frank
--
Frank Heckenbach, frank(a)g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
[View Less]
On Fri, 2003-02-28 at 15:09, Frank Heckenbach wrote:
<big snip>
> > 1) When moving the vars into the section in which they are declared
> > should I make a menu entry for each one or should I do a submenu of
> > vars?
>
> Good question. I'd say it depends. Sometimes, each one deserves its
> own entry, other times, there are a list of them which belong
> together (e.g., the color constants in the CRT unit).
>
> Of course, the program can't find this …
[View More]out automatically. One rule
> might be, if there's a comment for each of them, put them in
> separate sections, like here:
>
> var
> { Address of the lowest byte of heap used }
> HeapLow: PtrCard; asmname '_p_HeapLow'; external;
>
> { Address of the highest byte of heap used }
> HeapHigh: PtrCard; asmname '_p_HeapHigh'; external;
>
> { If set to true, `Dispose' etc. will raise a runtime error if
> given an invalid pointer. }
> HeapChecking: Boolean; asmname '_p_HeapChecking'; external;
>
Yes the above is going to strait forward to implement.
> But if there's only one comment at the top, put them in one section
> all together:
>
> const
> { Foreground and background color constants }
> Black = 0;
> Blue = 1;
> Green = 2;
> Cyan = 3;
> Red = 4;
> Magenta = 5;
> Brown = 6;
> LightGray = 7;
>
> Of course, in the indices, there should be entries for each of them.
Now this is tricky:
1) What do you call the node/section for this list of vars/functions
ect...?
2) You can't just assume that because there is not a comment that it
belongs to what was above. If you do what happens for those cases where
I haven't finshed writing the documentation for my code?
I'm thinking that to solve this we are going to need a group command.
Something like {@group group name} .... {@end group }
Where 'group name' would be the name used for the section/node.
And Yes I agree that every item needs to be placed in the index but what
happens in the case where you don't want them all in the index. maybe a
option to the @group command.
>
> > 2) If I where to put them in the section menu how about this menu sytle:
> >
> > @menu
> > * MaxInt:: Const
> > * SomeVar:: Var
> > * SomeType:: Type
> > * FuncFoo:: function
> > * ProcFoo:: Procedure
> > @end menu
> >
> > Or
> > @menu
> > * Const MaxInt::
> > * Var foo::
> > * Type foo::
> > * SomeFunc::
> > * SomeProc::
> > @end menu
>
> Since the left part of the menu corresponds to the node name, I
> prefer the former, so the node name equals the identifier.
>
> BTW, you sent this mail personally, so I'm replying personally. If
> it was meant for the list, feel free to forward and/or quote my mail
> there.
>
Sorry about that.. This one is going to the group...
> Frank
Oh FYI I've started to work on a manual for pas2texi. As soon as I get it roughed
in I will send a copy to the list.
Richard
[View Less]