RE: Just say 'YES' to strings
I cant personally figure out why anyone wouldn't like sequences, and what=
=20
something like strings. Because the only use of strings are to talk to=20
NON-euphoria things like other languages and dlls and stuff. I personally=
=20
like sequences cause Im unicode compilent for the next 50 years, or until=
=20
unicode>8 comes out, (like why would anyone need more that 2^32 is beyond=
=20
me) so anywhy just use sequences and strings are a subset of them, all you=
=20
need is somthing like allocate_string to pull the poinker(sting) out of a=
=20
sequence and give it to other things.
I would personally like if there were byte sequences for other reasons, but=
=20
find memory a great alternitive. And I would also like FLOAT32 only=20
sequences, but again alittle memory and alot of assembly and I'm over it.
The one thing that would be cool,
Number 1 A hash Sequence
What it would be
a linked list of pointers, each pointer being data item
the linked list is sorted
size changes are fast, and hash search is real quick
what it would look like
A normal sequence, just with faster "find" and automatically custom sorted=
=20
like every time it changed
it calls a compare routine, like "custom_sort" does
Number 2 A Spin Sequence
You start with a normal sequence, then
you set it to a bunch of data, then you slice and dice, then you add more=
=20
data, and slice and add
So every time you do this it takes along time cause memory coping and such
So instead, start with the normal sequence footprint in memory
with the TOtal length
and in the sequence pointed to by that, have a length and a link to the nex=
t=20
part.
This would be great for FIFO buffers, and the like.
sequence spinner
spinner=Alot of data
spinner=spinner[somthing..somthing]
spinner&=More data
spinerr=spinner[somthing..somthing]
spinner&=more data
Conclusion, I think those would be great, they have no special data type,=
=20
jsut a sequence full of objects.
Daniel
>From: Al Getz <Xaxo at aol.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: RE: Just say 'YES' to strings
>Date: Thu, 3 Jun 2004 09:47:44 +0000
>
>
>Hi there Kat,
>
>I had a feeling someone was going to bring up Unicode strings 
>Of course to handle that there would have to at least be a
>second 'type' such as C_UCSTRING (in addition to C_STRING).
>
>Not sure what you meant about the garbage collection though,
>maybe you could explain a little more? tia
>
>I guess a type 'byte' sequence (as someone else mentioned
>a long while back) might work together with the 'address of'
>operator. This way you could still make the sequence anything
>you wanted it to be (UNICODE, STRING, etc) yet have the starting
>address available to ship to your c function via 'address of' or
>whatever. In C of course this is available as the '&' prefix.
>
>I guess it would be useful to be able to use types on subsequences
>too.
>
>Take care,
>Al
>
>
>Kat wrote:
> >
> >
> > On 3 Jun 2004, at 4:07, Al Getz wrote:
> >
> > >
> > > Hello there,
> > >
> > > Im not sure if you all are talking about strings in general or
> > > what, but what i'd like to see in Eu is this...
> > >
> > > include cfunc_links.ew
> > > include string.e
> > >
> > > atom x
> > > string s
> > >
> > > s="Hello Mars"&0
> > >
> > > x=c_func(xSetWindowTitle, {s})
> > >
> > > Note in order for the above C function call to work properly
> > > the variable s would have to point to a memory location where
> > > the string is located. The string gets there via the 's' variable
> > > assignment statement.
> > >
> > > The thing about strings is if you know your variable is always
> > > a string then it not only makes calling C functions that require
> > > string arguments a lot easier it also means you can have better
> > > type checking.
> > >
> > > For those people who dont like using this they dont have to
> > > of course, and can continue using allocate_string() instead.
> > >
> > > It would be also possible to handle the string as both as string
> > > and a sequence. All the usual operators would still apply,
> > > except an Eu error would trigger if a program attemps to store
> > > a value greater then #FF or less then #00 to a string element.
> >
> > That still leaves out multi-byte unicode letters.
> >
> > > Examples:
> > >
> > > string s
> > >
> > > s="Hello there"&0
> > > ?s --Hello there
> > > s=s[1..5]&0
> > > ?s --Hello
> > > x=c_func(xMyCStringFunction,{s})
> > >
> > > It may even be possible to set it up so that you dont have
> > > to keep using a terminating zero:
> > >
> > > s="Hello"
> > > x=c_func(xMyfunc,{s})
> > >
> > > although there would probably have to be a way to prevent the
> > > zero terminator in some cases.
> > >
> > > Note in the above:
> > > x=c_func(xMyFunc,{s})
> > >
> > > when the function name "xMyFunc" is linked the type 'string'
> > > is registered internally, so trying to pass anything other
> > > then a string would trigger a Eu type error.
> > > Example:
> > > xMyFunc=LinkFunc(MyDll,"MyFunc",{C_STRING},C_ULONG)
> > >
<snip>
>
>
>
!=20
http://join.msn.click-url.com/go/onm00200361ave/direct/01/
|
Not Categorized, Please Help
|
|
