> > Sounds good. (Remind me why it couldn't appear before the main
program?)
>
> Because I'm too lazy to make it happen :-) Currently, all directives
> need to appear after the main part of the program. It would be
> possible to allow them there, and perhaps in a future release I will,
> but right now, allowing that fundamental change would be quite
> disruptive for a release that's in the home stretch. ::REQUIRES
> directives up front might be a good thing too. Restrictions like this
> are fairly easy to lift without breaking existing programs.
(OK, gotit. Yes, these are a good candidate for 4.x)
> >> All option values must be either a symbol taken as a constant or a
> >> literal string. No expression evaluation takes place with
directives,
> >> which are static source descriptors.
> >>
> >> The options are fairly self-explanatory, but I think there is a need
> >> for some keyword for DIGITS that means "use the same as the internal
> >> built-in setting". Looking for a name suggestion on that one.
> >
> > How about: 9 ? :-)
>
> But "9" is not the internal size for 64-bit systems. "9" in this
> proposal means always use numeric digits "9". We want an option that
> essentially says "use the setting that matches the size used
> internally by the BIFs."
OK, I didn't understand what was meant by 'internal size'. At the moment
I can't see any advantage of exposing internal limits (which could be
relaxed in a later implementation). They are also a bit vague: in the
32-bit is it 9 (for strings?) or 10 (for streams)? And why couldn't it be
bigger than that for streams even on a 32-bit system? [Aside: while
testing for the example I gave earlier I discovered that stream query size
gives a negative result for 2GB files, so this is a messy area, for sure.]
The
> >> STRICTNOVALUE is for people routinely enable NOVALUE traps in all
> >> code. This will raise a SYNTAX error in any situation where a
NOVALUE
> >> condition would be raised. I'm waffling on the keyword here
> >> too...perhaps this should be NOVALUE keyword with an option such as
> >> CONDITION/SYNTAX or RELAXED/STRICT. In the theory that you want to
be
> >> able to explictly specify all forms of an option, probably the last
> >> would be better.
> >
> > It could be: SIGNALON condition
> > and maybe allow: CALLON condition
> > too.
> >
> > (Perhaps only allow NOVALUE for the condition at first.)
>
> SIGNALON/CALLON to where? SIGNAL references internal labels, which
> are not visible across source "units" in a package. This really is a
> different chose, which is "raise an error rather than a condition".
I wasn't suggesting allowing specification of labels, more that (for
example)
::options signalon novalue
would have the same effect as adding
signal on novalue
at the start of each code segment. (i.e., it is simply defined as exactly
that, rather than adding a new concept). If there is a local novalue:
label then the signal would transfer control; if not you'd get the usual
'label not found' message.
Mike
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
