On Fri, Feb 27, 2009 at 12:50 PM, Mike Cowlishaw <m...@uk.ibm.com> wrote: >> > 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.]
Streams always work with the fully 64-bit integer range, even on 32-bit systems. That value allows full stream sizes to be accessed. That's in a completely different category from the string functions/methods where the normal "used internally rules apply". > 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. I don't really like that, since a more targetted message can be given for the 3rd state....and in ooRexx, SIGNAL ON NOVALUE with no label is one of those things that gives an immediate error rather than a runtime one. Rick > > 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 > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
