On Fri, Feb 27, 2009 at 12:13 PM, Mike Cowlishaw <[email protected]> wrote: >> I'm starting to come around to the position that the default digits >> setting should be 9 (not completely convinced yet, but close). >> However, I think that if this is done, then there are some additional >> things that need to be added. One is a ::options directive to allow >> these things to be tailored on a source file basis. So here's a >> straw-man proposal for a directive: >> >> ::OPTIONS DIGITS digits FORM form FUZZ fuzz TRACE trace STRICTNOVALUE >> >> All options are optional, and can be specified in any order or >> multiple times. Last one wins if there are multiples. The OPTIONS >> directive may appear anywhere after the main program section of the >> source file, and can be specified multiple times as well (last one >> wins applies here too, if an option appears on multiple directives). >> All options apply to all Rexx code contained within the source file. >> So for, example, including >> >> ::options digits 18 >> >> would mean that an initial digits setting of 18 will be used for all >> Rexx code created this source file. This includes the main program, >> all routines declared using ::ROUTINE, and all methods. > > 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. > >> 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." > >> 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". > >> Given that I'm going to the trouble of implementing this, I'd like to >> make it apply to more than just the digits setting, hence the >> additional options. > > Makes sense. > > 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 > ------------------------------------------------------------------------------ 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
