OpenEuphoria

2. Re: Strings

• Posted by Kat <KSMiTH at PELL.NET> Dec 10, 1999
• 572 views

There is a war over strings?

----- Original Message -----
From: Michael Nelson <mike-nelson-ODAAT at WORLDNET.ATT.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, December 10, 1999 1:04 AM
Subject: Strings


I really want to stay out of the war over strings, but I thought I'd share
the string type I use--easier to read than the others I've seen in these
posts, but should be comparably efficient:

global type string(object theObject)
object temp
if not sequence(theObject) return 0 end if
for i=1 to length(theObject) do
    temp=theObject[i]
    if not integer(temp) or temp<0 or temp>255 then return 0 end if
end for
return 1
end type

--Mike Nelson

4. Re: Strings

• Posted by Ryan W. Johnson <ryanj at fluidae.com> Feb 18, 2006
• 556 views

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?

~Ryan W. Johnson

Fluid Application Environment
http://www.fluidae.com/

[cool quote here, if i ever think of one...]

6. Re: Strings

• Posted by Al Getz <Xaxo at aol.com> Feb 18, 2006
• 554 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"

8. Re: Strings

• Posted by Bernie Ryan <xotron at bluefrog.com> Feb 18, 2006
• 562 views

All of my libraries already support memory based 
"C" type string handling which are written in
eurphoria assembler.

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

10. Re: Strings

• Posted by "Greg Haberek" <ghaberek at gmail.com> Feb 18, 2006
• 569 views

> Oh, and it looks like Euphoria *could* offer the programmer a way to chec=
k whether a variable has been initialized.

I proposed this a while ago. I believe object() should return true for
initialized, and false for unitinialized, like this:

sequence s

    if not object( s ) then
        -- not initialized!
        s = {}
    end if

~Greg

12. Re: Strings

• Posted by Shawn Pringle <shawn.pringle at gma?l.c?m> May 30, 2008
• 586 views

Matt Lewis wrote:
> 
> If someone can figure out an easy way to do this, I suspect it'd get into
> the language pretty quickly.  Of course, that ignores the prospect of 
> Unicode, which is a whole 'nother can of worms, and also something that
> will require some drastic recoding in the back end, though due to the
> way that sequences are implemented, probably none in the front end.
> 
> Matt
It seems you can do Unicode well enough already:

sequence shawn
shawn = { 's', 'h', #0430, 'w','n' } -- a is cyrillic a.

You can use poke2 from words.e or poke2 from my own pokpeek2.e
and use with a unicode C routine.  All manipulation works
like any another sequence

Shawn Pringle

14. Strings

• Posted by Mathew Hounsell <mfh03 at UOW.EDU.AU> Aug 05, 1999
• 596 views

Yes I'm going to wade into this again.
1st) memory conservation is good especially when there is a large amount of
waste.
2nd) speed decrease is not nice, but acceptable

because most importantly
***Type checking reduces error's***

It also reduce's the need for manual error detection which can get quite omplex
and slow
and consuming with euphoria. The alternative is to let the routine die from an
obscure error
and let the finger be pointed at the routine it dies in rather than the one who
started the
problem.

I will again say string's are good.

Consider the standard indexing on a sequence, it must require quite complex
operation's.
Where as the indexing on a string would require a simple bounds check, offset
calculation and a
peek.

As intel chips align to 4 bytes. Unless the string has a length which is a
multiple of 4 there
is a gap of up to 3 bytes to append into reducing the time for that.

There are many other benefits but I'm going to diner.
-------------------------
Sincerely,
Mathew Hounsell

mat.hounsell at excite.com