Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
The processor architecture only comes in to play with values that
referred to as numbers used directly by Rexx. This is generally the
internal digits setting used internally by bifs/methods, and for
things like do loops. These are the places where a Rexx number
need to be converted into native values. This is distinct from the
current numeric digits setting, which is what governs Rexx arithmetic.
So, for the last 30 years, both of these values have always been 9,
so everything remained in sync. You could still set numeric digits
higher for calculations, but if you tried to use 10 for a
substr position (for example), you would get an error for an invalid
whole number, since the substr() bif uses numeric digits 9
internally. All calculations that would evaluate as a whole number
under the default digits setting would also produce good values for
the bifs, and non-whole number results would generally be rejected.
The internal digits setting is unaffected by changes in NUMERIC
DIGITS. It always operates with the internal digits setting.
In the current 4.0 codebase, when compiled for 64-bit, the internal
digits setting is 18, which allows you to manipulate values larger
than 99. The default digits setting is also the same, which
means the symmetry from the 32-bit implementation is maintained. The
danger with decoulping these occurs when a bif such as pos() returns a
value that would not be considered a whole number under the current
digits setting (which btw, is a situation you can encounter if you are
running at a setting smaller than 9). If you use that value to
perform a calculation, you're likely to lose digits off the end,
creating a result with a high astonishment factor.
There has always been that 'astonishment factor' when (typically using
integers) more than 9 digits of precision are required for a calculation
to be exact. That's a consequence of the choice to go for readability --
a default of 9 digits -- rather than a higher precision by default.
Having 64-bit implementations does not change that; all 64-bit means is
that larger objects may be more common, so the astonishment may happen a
bit more often. The problem is already there in the 32-bit
implementation, so programmers already have to address the issue, so this
is not something that works in 32-bit but does not work in 64-bit.
For example, using 32-bit 3.2.0 (some irrelevant lines prompts deleted):
dir VTS_01_1.VOB
28/04/2005 11:41 1,073,692,672 VTS_01_1.VOB
say stream('VTS_01_1.VOB', 'c', 'query size')
1073692672
That result is more than 9 digits; if one is doing arithmetic on stream
sizes today, in a 32-bit environment, you must already be using a larger
numeric digits. (And I have to suspect that people probably set 12 or 15
digits, so increasing the default to 18 won't override that in any case.)
If short: if the argument is that the 9-digit choice was wrong in the
first place (which is a valid point of view) then the proposal should be
to change the _language_ to use a larger default (18, 20, whatever) -- and
that would then apply to all implementations, whether they run on 16-bit,
32-bit, or 64-bit platforms.
I really do not like the idea that
say 1/7
Might give 0.142857143 on one machine and 0.142857142857142857 on another,
just because one user installed the 32-bit version and another the 64-bit.
This would lead to all kinds of subtle problems of this nature (a toy
example):
if x/3 = 0.3 then say 'X is one'
which would work differently depending on which version one had installed.
However, I do like the idea of a directive like
::numeric digits 18
that would apply to a complete program/class. That would be useful anyway
(as would similar for other 'global defaults', such as Trace setting). :-)
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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
Mike Cowlishaw wrote:
The processor architecture only comes in to play with values that
referred to as numbers used directly by Rexx. This is generally the
internal digits setting used internally by bifs/methods, and for
things like do loops. These are the places where a Rexx number
need to be converted into native values. This is distinct from the
current numeric digits setting, which is what governs Rexx arithmetic.
So, for the last 30 years, both of these values have always been 9,
so everything remained in sync. You could still set numeric digits
higher for calculations, but if you tried to use 10 for a
substr position (for example), you would get an error for an invalid
whole number, since the substr() bif uses numeric digits 9
internally. All calculations that would evaluate as a whole number
under the default digits setting would also produce good values for
the bifs, and non-whole number results would generally be rejected.
The internal digits setting is unaffected by changes in NUMERIC
DIGITS. It always operates with the internal digits setting.
In the current 4.0 codebase, when compiled for 64-bit, the internal
digits setting is 18, which allows you to manipulate values larger
than 99. The default digits setting is also the same, which
means the symmetry from the 32-bit implementation is maintained. The
danger with decoulping these occurs when a bif such as pos() returns a
value that would not be considered a whole number under the current
digits setting (which btw, is a situation you can encounter if you are
running at a setting smaller than 9). If you use that value to
perform a calculation, you're likely to lose digits off the end,
creating a result with a high astonishment factor.
There has always been that 'astonishment factor' when (typically using
integers) more than 9 digits of precision are required for a calculation
to be exact. That's a consequence of the choice to go for readability --
a default of 9 digits -- rather than a higher precision by default.
In the 16-Bit world this meant that Rexx number values could be larger
than the processor's largest integer that usually would have been used
by assembled and compiled languages (offering external functions), which
I still think has been a very remarkable (and excellent) decision! This
also meant that for all practical purposes using NUMERIC DIGITS was not
needed if interfacing with external functions (receiving large numbers,
calculating with them, supplying them back).
Having 64-bit implementations does not change that; all 64-bit means is
that larger objects may be more common, so the astonishment may happen a
bit more often. The problem is already there in the 32-bit
implementation, so programmers already have to address the issue, so this
is not something that works in 32-bit but does not work in 64-bit.
For example, using 32-bit 3.2.0 (some irrelevant lines prompts deleted):
dir VTS_01_1.VOB
28/04/2005 11:41 1,073,692,672 VTS_01_1.VOB
say stream('VTS_01_1.VOB', 'c', 'query size')
1073692672
That result is more than 9 digits; if one is doing arithmetic on stream
sizes today, in a 32-bit environment, you must already be using a larger
numeric digits. (And I have to suspect that people probably set 12 or 15
digits, so increasing the default to 18 won't override that in any case.)
This is exactly the problem in today's world where we deal with 64-Bit
and shortly in the future with 128-Bit and more. Interfacing with
compiled languages that take advantage of the register sizes exceeds all
of a sudden the Rexx default capability. Getting and calculating with
numbers from external functions all of a sudden cause them to be edited
by Rexx, loosing digits in the process, which in the past did simply not
happen.
This is where a real problem starts: Rexx programs all of a sudden stop
working correctly! Enclosed you'll find a small Rexx utility that I
wrote in the OS/2 days 17 years ago which would break up large files
into chunks that did fit on diskettes and generating a copy command to
reassamble the chunks to allow the original file to be recretated. (As
strange as it may seem) That very same program may be still useful in
splitting up large files for CDs or even DVDs! Just take into account
multiemedia files (digital - home - videos). (Believe it or not, that
Rexx program was faster on Windows machines than specialized, compiled
programs!)
It was with this little program that I noted for the first time a couple
of years ago, that in todays hardware environment the digits settings of
9 is becoming a serious bottleneck, causing Rexx programs that used to
run for decades to all of a sudden to fail! I think that is not
acceptable and needs to be solved once and forever! It is probably not
feasible/possible to go after all existing programs and insert a NUMERIC
DIGITS 20 (and then with 128-Bit processors and
[Oorexx-devel] Thinking about an ::options directive.
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. 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.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. 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. Rick -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
On Fri, Feb 27, 2009 at 5:42 AM, Rick McGuire object.r...@gmail.com wrote: I'm starting to come around to the position that the default digits setting should be 9 (not completely convinced yet, but close). I'm not entirely convinced either. But, if you and Mike reach a consensus on it, then I'm content to go with that. Personally, I don't buy the readability argument. 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. The ::options directive is in and by itself a great idea. However, if the decision is to go with a default of 9 digits for the 64-bit build, then I think it is a must. I gotta run now, I'll thing about a keyword that means use the same as the internal built-in setting. -- Mark Miesfeld -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
DEFAULT is not a good choice, since DEFAULT is 9, not the higher value value of 18 that is the target. * is also not a great choice, since Rexx has generally avoided using that as a wildcard option. Yes, but you'd only specify the NOVALUE option if you weren't doing that trapping. It would only apply to the source file that contains the ::OPTIONS directive, not to any other code, so none of your code would break. Rick On Fri, Feb 27, 2009 at 8:53 AM, John Bodoh john_bo...@infrawise.com wrote: Sound good to me. The keyword for use same as internal build-in setting should be something non-numeric. The word DEFAULT expresses some meaning while * is easier to code. Changing a NOVALUE condition to a SYNTAX condition would break code that I have that explicitly handles NOVALUE. John -Original Message- From: Rick McGuire [mailto:object.r...@gmail.com] Sent: Friday, February 27, 2009 8:43 AM To: Open Object Rexx Developer Mailing List Subject: [Oorexx-devel] Thinking about an ::options directive. 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. 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. 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. 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. Rick -- 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 -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
Mark Miesfeld wrote: On Fri, Feb 27, 2009 at 5:42 AM, Rick McGuire object.r...@gmail.com wrote: I'm starting to come around to the position that the default digits setting should be 9 (not completely convinced yet, but close). I'm not entirely convinced either. But, if you and Mike reach a consensus on it, then I'm content to go with that. Personally, I don't buy the readability argument. 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. The ::options directive is in and by itself a great idea. However, if the decision is to go with a default of 9 digits for the 64-bit build, then I think it is a must. I gotta run now, I'll thing about a keyword that means use the same as the internal built-in setting. -- Mark Miesfeld -- 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 I can live with an OPTIONS directive. And I have NEVER agreed with the readability argument. My programs have way too many instances where the readability limit places far too many limitations on my math calculations. I much prefer precise results over the surprise factor of loosing digits unexpectedly. Therefore I am constantly placing a NUMERIC DIGITS 14 at various places in my programs. And I would like to make one last point about the readability philosophy. If you examine any Rexx program and count the number of numeric objects that are used or generated in the program, you will typically find that 90% or more of those objects never get displayed except during the debugging cycle of the program. And those that do get displayed to the user are almost always formatted in some way. In fact, I would say that most users will not accept a program that does not format numbers for readability. Therefore, the readability argument just does not hold water in most circumstances as an argument for limiting the number of digits. It is strictly a easy limit to help the programmer, but it turns out to be an impediment to producing precise calculations for production programs. As a systems administrator I am always writing Rexx programs to calculate disk usage, file size, memory capacity, and other such large value objects. I constantly have to think about the 9 digit limit on my calculations in such programs. The default of 18 digits in the 64-bit environment was going to be a real help to me and I was not happy about reverting it to 9. At least with the OPTIONS directive I can easily globalize a new setting. David Ashley -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
Let me first say that I am in favor of a mechanism to globally specify the various items that have been proposed for ::options. But I am not clear on why this needs to be a new directive when the language and standard provide for the OPTIONS keyword. Any help would be appreciated :-) David Ashley wrote: Mark Miesfeld wrote: On Fri, Feb 27, 2009 at 5:42 AM, Rick McGuire object.r...@gmail.com wrote: I'm starting to come around to the position that the default digits setting should be 9 (not completely convinced yet, but close). I'm not entirely convinced either. But, if you and Mike reach a consensus on it, then I'm content to go with that. Personally, I don't buy the readability argument. 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. The ::options directive is in and by itself a great idea. However, if the decision is to go with a default of 9 digits for the 64-bit build, then I think it is a must. I gotta run now, I'll thing about a keyword that means use the same as the internal built-in setting. -- Mark Miesfeld -- 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 I can live with an OPTIONS directive. And I have NEVER agreed with the readability argument. My programs have way too many instances where the readability limit places far too many limitations on my math calculations. I much prefer precise results over the surprise factor of loosing digits unexpectedly. Therefore I am constantly placing a NUMERIC DIGITS 14 at various places in my programs. And I would like to make one last point about the readability philosophy. If you examine any Rexx program and count the number of numeric objects that are used or generated in the program, you will typically find that 90% or more of those objects never get displayed except during the debugging cycle of the program. And those that do get displayed to the user are almost always formatted in some way. In fact, I would say that most users will not accept a program that does not format numbers for readability. Therefore, the readability argument just does not hold water in most circumstances as an argument for limiting the number of digits. It is strictly a easy limit to help the programmer, but it turns out to be an impediment to producing precise calculations for production programs. As a systems administrator I am always writing Rexx programs to calculate disk usage, file size, memory capacity, and other such large value objects. I constantly have to think about the 9 digit limit on my calculations in such programs. The default of 18 digits in the 64-bit environment was going to be a real help to me and I was not happy about reverting it to 9. At least with the OPTIONS directive I can easily globalize a new setting. David Ashley -- 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 -- Gil Barmwater -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
The OPTIONS keyword instruction is an executable instruction that really only applies to the context in which it is executed. Directives are metadata that are outside of an execution context and apply to everything globally. As a directive, it can direct the language translater on how things should be processed without need to delay processing until runtime. And since it is not dependent upon execution-time evaluation of the instruction, it has a bit more upfront freedom to optimize the decision making. Each has its place, but these types of options are really most appropriately applied using the directive form. Rick On Fri, Feb 27, 2009 at 10:59 AM, Gil Barmwater gbarmwa...@alum.rpi.edu wrote: Let me first say that I am in favor of a mechanism to globally specify the various items that have been proposed for ::options. But I am not clear on why this needs to be a new directive when the language and standard provide for the OPTIONS keyword. Any help would be appreciated :-) David Ashley wrote: Mark Miesfeld wrote: On Fri, Feb 27, 2009 at 5:42 AM, Rick McGuire object.r...@gmail.com wrote: I'm starting to come around to the position that the default digits setting should be 9 (not completely convinced yet, but close). I'm not entirely convinced either. But, if you and Mike reach a consensus on it, then I'm content to go with that. Personally, I don't buy the readability argument. 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. The ::options directive is in and by itself a great idea. However, if the decision is to go with a default of 9 digits for the 64-bit build, then I think it is a must. I gotta run now, I'll thing about a keyword that means use the same as the internal built-in setting. -- Mark Miesfeld -- 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 I can live with an OPTIONS directive. And I have NEVER agreed with the readability argument. My programs have way too many instances where the readability limit places far too many limitations on my math calculations. I much prefer precise results over the surprise factor of loosing digits unexpectedly. Therefore I am constantly placing a NUMERIC DIGITS 14 at various places in my programs. And I would like to make one last point about the readability philosophy. If you examine any Rexx program and count the number of numeric objects that are used or generated in the program, you will typically find that 90% or more of those objects never get displayed except during the debugging cycle of the program. And those that do get displayed to the user are almost always formatted in some way. In fact, I would say that most users will not accept a program that does not format numbers for readability. Therefore, the readability argument just does not hold water in most circumstances as an argument for limiting the number of digits. It is strictly a easy limit to help the programmer, but it turns out to be an impediment to producing precise calculations for production programs. As a systems administrator I am always writing Rexx programs to calculate disk usage, file size, memory capacity, and other such large value objects. I constantly have to think about the 9 digit limit on my calculations in such programs. The default of 18 digits in the 64-bit environment was going to be a real help to me and I was not happy about reverting it to 9. At least with the OPTIONS directive I can easily globalize a new setting. David Ashley -- 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 -- Gil Barmwater
Re: [Oorexx-devel] Thinking about an ::options directive.
Let me first say that I am in favor of a mechanism to globally specify the various items that have been proposed for ::options. But I am not clear on why this needs to be a new directive when the language and standard provide for the OPTIONS keyword. Any help would be appreciated :-) For a program that's stand-alone in a file, the OPTIONS instruction is fine, but the ::OPTIONS directive would apply to all methods/subroutines/functions in a file. Actually it would make sense to define these as a OPTIONS instruction, and then just say that ::OPTIONS is just like putting OPTIONS at the start of every routine. Then programmers could mix match as desired. 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
Re: [Oorexx-devel] Thinking about an ::options directive.
On Fri, Feb 27, 2009 at 5:42 AM, Rick McGuire object.r...@gmail.com wrote: 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. I think either NATIVE or INTERNAL would make sense to the committers and anyone else that follows this list closely. Not sure that it would make sense to everyone else without some education. On the other hand, almost any keyword we pick would probably require some education. INTERNALDIGITS seems good to me. After a simple explanation, I think it would be easy to remember. -- Mark Miesfeld -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
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?) 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 ? :-) 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.) 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about an ::options directive.
On Fri, Feb 27, 2009 at 9:13 AM, Mike Cowlishaw m...@uk.ibm.com wrote: ::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?) The first directive marks the end of the end of the main executable portion of the program. 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, on a 64-bit platform with a 64-bit build, you would want it to be 18 - so 9 seems a little confusing. Or, did I misunderstand what you meant, as I do quite often. grin -- Mark Miesfeld -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
On Fri, Feb 27, 2009 at 9:13 AM, Mike Cowlishaw m...@uk.ibm.com wrote: ::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?) The first directive marks the end of the end of the main executable portion of the program. 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, on a 64-bit platform with a 64-bit build, you would want it to be 18 - so 9 seems a little confusing. Or, did I misunderstand what you meant, as I do quite often. grin -- Mark Miesfeld -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
On Fri, Feb 27, 2009 at 12:13 PM, Mike Cowlishaw m...@uk.ibm.com 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 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
Re: [Oorexx-devel] Thinking about an ::options directive.
::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?) The first directive marks the end of the end of the main executable portion of the program. Ah yes, thanks .. that's why one can't put ::requires up-front, too. I remember now... 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, on a 64-bit platform with a 64-bit build, you would want it to be 18 - so 9 seems a little confusing. Or, did I misunderstand what you meant, as I do quite often. grin No, I misunderstood what was intended by this. And I suppose I don't really understand why one would want a setting that would give a different result depending on which platform/implementation one happened to be running on. Doubles the testing load, again. Why, if writing and worrying about 64-bit big objects, wouldn't one just used DIGITS 20 and be done with it? 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
Re: [Oorexx-devel] Thinking about an ::options directive.
How about: 9 ? :-) ::honest laughter here:: By the way, I want to personally thank you for making a large part of what I do and have done possible or at the very least, much easier and faster to accomplish. If you don't hear that frequently, you should. Robert -- 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
Re: [Oorexx-devel] Thinking about an ::options directive.
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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about an ::options directive.
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 stateand 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
