On 26 August 2013 16:30, David Korn <[email protected]> wrote:
> cc: [email protected]
> Subject: Re: Re: [ast-developers] [uwin-developers] Next alpha/beta and
> roadmap for ksh93v?
> --------
>
>> >>
>> >>> Why? How should I construct scripts from that using variables, i.e.
>> >>> use typeset -s -E svar; printf 'typeset -s -E var; for ((var = %s; var
>> >>> < %s; var+= %s)); do myfunc var; done' ${svar.MIN} ${svar.MAX}
>> >>> $((2**24)) | source /dev/stdin
>> >>>
>> >>>
>> >>>
>> >> svar.MIN and svar.MAX will exist, but only in arithemtic expressions.
>> >> Thus, $((svar.MIN)) and $((svar.MAX)) instead of ${svar.MIN} ${svar.MAX}.
>> >> Only constants like PI, NaN, Inf, and others will not exist for each
>> >> type.
>> >> The limits would.
>> >
>> > I don't understand this. The patch
>> > astksh20130814_math_constants001.diff.txt already allows MIN, MAX,
>> > EPSILON etc if they are defined in .sh.mathconst. Why is the
>> > functionality now restricted to $(())? It just makes it much harder to
>> > use, if usable at all.
>>
>> Right. I don't like David's approach either, unless there is a very
>> damn good justification for castrating numeric constants to $(()) and
>> not for ${}. Given that Roland's patch works, minus having
>> preconfigured constants, and can be extended to cover enums (bool is
>> an enum) I don't see a reason for not taking that patch.
>>
>> Irek
>>
>
> OK, let me preset some reasons:
>
> 1. These variables are only arithmetic related. Just like NaN, nan,
> Inf, and inf which also don't give the same result for ${NaN} and
> $((NaN)).
That may be bad, but then it could be written as ${val.NAN}. NAN and
INF/-INF are specific to the floating point type anyway.
>
> 2. The implementation is inconsistant in that ${!foo*} does not
> expand all integer variables starting with foo to each of the
> 18 integer or 27 possible float suffices for integer and float
> respectively.
This would violate type-safety. The ${!foo.*} should only expand to
the names of the constants *valid* for the type of variable foo and
not all possible constants.
> 3. Rolands implementation used about 2500 bytes of read write
> memory which will be copied for each fork(). Mine use 0 more
> bytes of read/write memory.
I wouldn't mind of loosing 2k of memory if the code does what a
mathematician expects from the code
> 4. There is no additional functionlity created by allowwing ${i.MAX}.
I disagree. I even provided the example why it's important.
>
> I am planning to only support enum.constant in numerical expressions
> as well where it belongs.
Why? Like C++, JAVA, Fortess, python etc enums are numeric types and
thus should have the same behaviour as all other numeric types.
This example should IMO just work:
function f
{
nameref nv=$1
print "maxval=${nv.MAX}"
}
if (( condition1 ))
bool val
else
integer val
fi
f val
Tina
--
Tina Harriott - Women in Mathematics
Contact: [email protected]
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
