OpenEuphoria

Re: Euphoria 2.5 Features..... ??

• Posted by Isaac Raway <isaac-topica at blueapples.org> Dec 12, 2003
• 651 views

I think perhaps you misunderstand me, so let me try again with more of 
my own words.

I agree that Euphoria would benefit from having strings, however I 
believe that they should be defined in terms of a sequence.

I strongly disagree that a character is not an object. In the most 
global sense of the word "object" (which is the sense we should employ 
when discussing any change like this to a language), *everything* is an 
object. Besides, a character can be easily defined in terms of the type 
construct.

I believe that the correct way to go about adding "strings" to Euphoria 
is to modify the way a variable is define. So, if you wanted to define a 
string as in the example you used, when you write

	string Name

you are really saying to the language

	sequence of char Name

The langauge would then make optimizations for the variable Name so that it is
stored in a way specific to the data type char. (Note that there may need to be
the additon of a construct specifying this storage method.)

Using this system allows much more felxibility and therefore would be 
much more valuable if implemented than the addition of strings as their 
own data type.

It is good to keep the the basic parts of a language as simple as 
possible. If we only slightly modify the definition of sequence to by 
either (a) an ordered set of arbitrary objects, or (b) an ordered set of 
a given object type, then we have made a very valuable addition to the 
language.

Peace and Euphoria,

~ Isaac


Derek Parnell wrote:

>
>
>----- Original Message ----- 
>
>>From: Isaac Raway 
>>To: EUforum at topica.com 
>>Sent: Friday, December 12, 2003 4:56 PM
>>Subject: Re: Euphoria 2.5 Features..... ??
>>
>>
>>Concerning strings; Paul Graham Wrote an excellent 
>>article a few months ago that has a section very 
>>pertinent to this concept of adding a string type.
>>By the way, my final vote is *don't add strings*, 
>>just make the interpreter optimize sequences that 
>>are only made of characters. We don't need a 
>>string data type. We just need the sequence data 
>>type to be a bit smarter.
>>
>
>Well, I tend to have a different opinion. That's because I view the current
>Euphoria idiom of a sequence as being a variable length list of objects, but a
>string is a variable list of characters. And we all know that an object is not
>the same as a character. An object is an entity whose value's datatype can be a
>sequence, atom, or integer, with no additional  restrictions on their value
>domain. But a character is an integer and is constrained to the value domain zero
>to some upper limit, depending on the encoding method in use. For example, ASCII
>and UTF-8 have the upper limit of 255, UTF-16 has the upper limit of 2^16, etc...
>
>
>The problem we have with Euphoria is that there is no way that we can tell it
>that a sequence CAN only contain characters in an effecient manner. The 'type'
>mechanism can be used, but it has some overheads.
>
> type string(sequence x)
>  for i = 1 to length(x) do
>    if not integer(x[i]) then
>        return 0
>    end if
>    if x[i] < 0 or x[i] > EncodingMaxLimit then
>        return 0
>    end if
>  end for
>  return 1
> end type
>
>Now we can force Euphoria to support strings, but still not waste RAM.
>
>string Name
>Name = "Derek" -- okay, this works.
>Name[3] = 2.345 -- This should now fail.
>
>But without this 'hint', Euphoria would be quite happen to turn a 'string' back
>in to an ordinary sequence again.
>
>Thus, I would argue that a string type needs to be built into Euphoria before
>we gain both efficiency in speed and in RAM usage.
>
>