Re: Proposal for a (small) enhancement to the value() function.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Juergen Luethje wrote:
> 
> I see now what you mean. However, I still don't know whether it's a good
> idea to change the value() function in the proposed way.
> 
> CChris wrote:
> 
> > value() is meant to read any Euphoria object out of a string, the same way
> > get()
> > reads it out of a file, as written in the docs. This has nothing to do with
> > numeric values.
> 
> Of course value() has got something to do with numeric values.

Barely, and not mainly. A least, I have hardly ever used it for that purpose.

> Although I learned now that value() can be used differently, I think
> most people use value() just for converting e.g. "12345" to 12345.

Well, more feedback wanted from the list and indirectly from others.

> And when I recall what people wrote on EUforum during the last years,
> there was the wish for a _simpler_ value() function now and then.
> On the RDS homepage it reads: "Simpler than Basic". Now imagine somone
> who knows some Basic flavour and makes her/his first experiences with
> Euphoria. S/he is looking for the Euphoria equivalent of Basic's val()
> and finds in the documentation something like:
> | s = value(st)
> | where s consists ofthe following elements:
> |  {status code,
> |   value read,
> |   number of characters read,
> |   number of leading whitespace characters}
> 
> The person probably will think: "Simpler than Basic?? Can only be a joke."
> 

Sorry, but that "simple" mantra has caused Eu a lot of harm, because the user
has to code many things himself which s/he would find ready made in other
languages. Probably one of the reasons its use hardly spreads.

As for the Val() function in Basic, how does it signal an error? Further, it
doesn't decode strings if I remember corrctly. Perhaps a get_number(sequence s)
function, returning "" on error, would be useful as well, I'm not against it at
all.

> > If I say x=value({34,65,66,67,34}),
> > I get {0,"ABC"} in x, which translates into having read the sequence "ABC".
> > Not a numeric value, but the expected one. One has value(sprint(x))={0,x}
> > always,
> while</font></i>
> > sprint(value(s)[2]),
> > if the syntax were valid and s represents a valid object,
> > is a compressed form of s with all syntactically useless whitespace removed.
> > 
> > The only point is to make value() to also return information on its reading
> > job. This is very useful, since a string may contain several consecutive
> > valid
> > string representations of Euphoria objects. This information is available
> > inside
> > get.e; I'm making it available outside it. The main reason I had needed this
> > is related to text parsing, but more applications can be thought of.
> > Besides,
> > there is no Euphoria standard function which is "meant for text processing
> > or
> > text parsing", so it seems natural to extend value() this way, and does not
> > break any language design logic.
> 
> Even with your proposed change, value() would not become a "full-blown"
> text parsing function. I.e. for most text parsing needs additional
> functions will be required anyway. So I see no advantage in making value()
> more complicated then necessary, thereby breaking backwards compatibility.
> 

A non nested sequence of length 4 is more complicated than one of length 2? I
really didn't expect that one.

Could you provide an example where the proposed change breaks backward
compatibility?

> Also, there are already text-parsing routines in the User contributions.
> If you think such function(s) should be included in the official Euphoria
> release, then it would be much better to provide new, really powerful and
> versatile text parsing functions, which also will have appropriate names
> that reflect the purpose of the functions.
> 

You seem to have locked on the text parsing and reformatting uses, overlooking
the "simple" fact that, if a string has several object representations
concatenated inside it, the current value() doesn't allow to extract them all,
contrary to what you can do with get() on a text file.

CChris
> Regards,
>    Juergen

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu