There's a similar problem of a program not scaling to handle larger
data amounts available with 64-bits.  Since methods/bifs will function
internally with different values than the default, it means these
functions can return numeric values that will lose precision
unexpectedly in ways that won't occur on 32-bit implementations
because of inherent limitations of the address space.  Regardless of
choice, there are programs that can behave differently between 32-bit
and 64-bit.  The only real way to prevent this would be to keep the
default and the internal digits usage at 9 and impose data length
restrictions.  At this point, the only benefit of 64-bit becomes the
ability to create "more" things rather than "bigger" things.  But
imposing size restrictions like that runs counter to the spirit of
Rexx and isn't desirable either.

One approach would be to add an ::options directive that allows a
package to set how the default should be handled for code within a
package file.  You could chose it directly, or have an option that
says essentially "use native".  Given something like this, I'm less
opposed to pinning the default at the lower value.  This would also
fix an issue that a lot of people complain about, that it's necessary
to up numeric digits for every method of a class, sort of killing two
birds with one stone.  An equivalent keyword for NUMERIC digits would
probably be nice too.

Rick

On Thu, Feb 26, 2009 at 12:05 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 8:09 AM, Rick McGuire <object.r...@gmail.com> wrote:
>
>> This is directed primarily to the project committers.  Mike Cowlishaw
>> has raised the issue that the default digits setting for 64-bit
>> implementations should remain at 9 digits rather than being raised to
>> the higher value of 18 that will be used for "numbers used internally
>> by Rexx".
>
> I've been following that of course.  Unfortunately, I'm not sure that
> my background lends much weight to my conclusions.  If anyone
> remembers, I'd prefer to have it as big as a 64-bit number allows.
> <grin>  Both Rick *and* Mike talked me out of that.
>
>> I'm not terribly in favor of this,
>
> I'm not either.  But, I have a high regard for Mike's opinion, as I'm
> sure we all do, so I think we do need to take some time to decide what
> to do here.
>
> * The one point Mike made about the same program running on the same
> OS producing different results depending on the CPU type, is the point
> I'm most concerned about.
>
> * If the 'right' thing to do is change the default back to 9 on the
> 64-bit builds, then I think that the delay it causes is necessary.
>
> Still, I can't think of any program I have done, or would have done,
> that would fail if the default numeric digits was bigger at some time
> in the future than it was at the time I wrote it.
>
> That doesn't mean that those programs don't exist, but (I just read
> David's post,) I have to wonder if those programs really do exist, or
> it is just a hypothetical 'they could exist.'
>
> --
> 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
>

------------------------------------------------------------------------------
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

Reply via email to