OpenEuphoria

Re: Strings

• Posted by Jason Gade <jaygade at yahoo.com> Feb 18, 2006
• 649 views

Ryan W. Johnson wrote:
> 
> Jason Gade wrote:
> > 
> > Okay, so I'm going to propose two things with regards to strings. Even
> > though
> > I said that I wouldn't propose new stuff. Plus, I suppose it could be
> > handled
> > by ESL (once we get around to it) if it isn't implemented internally
> > (preferred0.
> > 
> > A string built-in data type with:
> > Byte-size ASCII strings. For Kat, since she can't have goto.
> > Unicode UTF-8 strings.
> > One built-in type should be able to handle both.
> > 
> > Atom has integer as a subclass for efficiency. I think that sequence can
> > have
> > string as a subclass as well, since strings are a "basic" type in most
> > programming
> > projects. Strings can be up-cast to sequences, like integers can be up-cast
> > to atoms.
> 
> I would be very happy if this was implemented!  Is there any
> reason to not have built-in strings?

I admit I was tired and bored last night when I posted that. I've been thinking
about it all morning.

One reason for *not* having built-in strings is that sequences handle 99% of the
functionality of strings already.

This proposal would get more complicated when you want sequences of strings as
well. The string type would only be able to apply to a single-level sequence.

But a question that occurs to me is what percentage of sequences in any given
Euphoria application represent text strings?

I think it really only matters for efficiency when working with large amounts of
text data. Because sequence elements are 4-bytes each.

So, basically, I retract my proposal. 

But it was helpful for reminding me of what features I want to see in an
Euphoria Standard Library string module.

> ~Ryan W. Johnson
> 
> Fluid Application Environment
> <a href="http://www.fluidae.com/">http://www.fluidae.com/</a>
> 
> [cool quote here, if i ever think of one...]


--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.