Re: Proposal for a (small) enhancement to the value() function.
CChris wrote:
> 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.
So what? What you personally are doing is not representative of all the rest.
>> 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.
People have written about this subject during the last years. And in
this thread, there is an interesting post by Derek Parnell, who beyond
any doubt is one of the most experienced Euphoria programmers. Derek
replied to you on 2007-06-27:
| Wow! I never knew it was a general purpose routine. I thought it only
converted
| a string to a number and I've only ever used it for that purpose.
This quote speaks volumes.
>> 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,
False.
> 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.
You are artificially creating a contradiction here which in this form
doesn't exist in reality.
The paradigm of simplicity is an essential part of Euphoria's philosopy.
Euphoria's power and elegance are partly due to its simplicity.
Several people (including me) have written about it in the past. However,
it seems to be impossible to explain Euphoria's elegance by words to people
who don't have a feeling for it.
If Euphoria wouldn't be simple anymore, it wouldn't be Euphoria anymore.
And it doesn't make sense to turn Euphoria into "the 327th BASIC flavour".
The challange is, to improve the language _whitout_ reducing its elegance
and simplicity. This is possible.
> As for the Val() function in Basic, how does it signal an error?
There are many different BASIC flavours. Probably not all flavours handle
this the same way.
> Further, it doesn't decode strings if I remember corrctly.
Believe it or not, BASIC's val() function converts a string that contains
a number, to a number (e.g. "12345" --> 12345).
> Perhaps a get_number(sequence
> s) function, returning "" on error, would be useful as well, I'm not against
> it at all.
The established name for this kind of operation is val() in BASIC, and value()
in Euphoria. Please see Derek's quote above.
>>> 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.
Reading the replies of other people to my previous post, it's obvious that
_they_ did understand very well what I wrote and what I mean.
> Could you provide an example where the proposed change breaks backward
> compatibility?
You provided an example yourself in one of your recent posts.
>> 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.
The details are not important. Whatever you want to do -- create a new function
for it,
give it an appropriate name, and let value() alone.
And since you seem to be the only one who needs such a function, it probably
should _not_
be built into the language.
Regards,
Juergen
|
Not Categorized, Please Help
|
|
