cc: [email protected] [email protected] Subject: Re: Re: [ast-developers] [uwin-developers] Next alpha/beta and roadmap for ksh93v? --------
> 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 > > roadma > p 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)). > > I like Mrs. Harriott's solution of x.NAN, i.e. make NAN a per type > constant analogous to > http://docs.oracle.com/javase/7/docs/api/java/lang/Float.html#NaN or > python float('nan') If you want a typeset -sE Nan, you can do typeset -sE x=NaN and x will be a float sized NaN. > > > 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. > > Can this be added for Mr. Mainz's patch? I suppose that it could, but not worth it. > > > > > 3. Rolands implementation used about 2500 bytes > > 2500 bytes per variable or 2500 bytes per shell session? 2500 bytes > isn't much - ksh93 requires at least 4MB to run on a 64bit machine, in > a world where mobile phones have 1GB and lowend desktops have 8GB > memory. > > > of read write > > memory which will be copied for each fork(). Mine use 0 more > > bytes of read/write memory. > > What you loose is flexibility. The flexibility of user-defined > constants or even typed functions. I've experimented with Mr. Mainz's > patch a bit and found it useful to add functions to floats: > ksh -c 'compound .sh.mathconst=( float LDBL_MYVAL=nan ) ; function > .sh.mathconst.LDBL_MYVAL.getn { .sh.value=4 ; } ; float x=5.5 ; print > $((x.MYVAL)) ${x.MYVAL}' > 4 4 To me, this is a reason against it. I don't want constants that are not constant and differ by type. > > > > > 4. There is no additional functionlity created by allowwing ${i.MAX}. > > Why do you think that? Even C++ and python have implicit string > conversions and Java has the Object.toString() function, which is sh's > equivalent to float x; ${x} x=$((x)) gives is equivalent. I don't think that i.MAX should be a real variable. If it is then how to does Roland's code handle nameref ref=i.MAX print ${ref.__} > > Wendy > David Korn [email protected] _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
