OpenEuphoria

Re: Strings

• Posted by Al Getz <Xaxo at aol.com> Feb 18, 2006
• 643 views

Jason Gade wrote:
> 
> 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.


Hi again,


You're right in that the main advantage to having a string type
would be mostly in making a text editor, where there is so much
text the memory savings would be great, but yes, quite a few
apps wont benefit much with *that* kind of definition of 'string'.
There is, however, another definition of 'string' where it's actually
a memory element:

string s
s="My Window"

where internally s is a pointer to the string, so it can be passed
to a C function like:

x=CreateWindow(s,...)

without having the bother of s=allocate_string("My Window").

This would mean other function such as 'printf(..)' would
have to also support this new kind of data type:

printf(1,"%s\n",{s})

where Euphoria would recognize 's' as a memory string object and
make the necessary call to print that type of object rather than
say a sequence string.



Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"