Re: Eu integers [was eternity]
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Bernie Ryan wrote:
> > > The whole complication comes down to the fact that Euphoria
> > > has sequences ( which is the greatest value of Euphoria ).
> > >
> > > Remember at any point in a sequence there can be a pointer
> > > to another sequence or a 32bit number and there has to be
> > > someway to tell the difference.
> >
> > The pointer doesn't need to point to actual data (which is why there must be
> > some way to tell the difference), but to some type info. Either the type
> > info
> > and data are in the same dword or in adjacent dwords. That way, we could get
> > rid of those clunky shortened integers, and add a few other types as needed.
>
> The best way might be to keep atoms and integers, and extend the sequence
> concept. Basically, keep the sequence object, but add different types of
> seuqences. We could add something to the structure to identify what it
> is, so that we could have an 8-bit char string, a UTF-16 string, or
> whatever.
>
> This is similar to one of the ideas floated back when we were kicking around
> adding some additional structured data types. Basically, it would maintain
> the speed advantage of atoms and integers, and would 'only' require rewriting
> the portions around sequences, though, admittedly, this would still be quite
> large. And we'd have to figure out what to do about things like 'char'
> overflow, casting between a sequence and a string, etc.
>
> IMO, it's not really prudent (or maybe even possible) to design an
> implementation before a lot of these issues are addressed.
>
> Matt
As you said some time ago, people won't agree on all the needed details for a
simply combinatorial reason (agree with this, not with that, or perhaps with this
one but with another name, everyone with his own mix). Do you think your approach
will lead in any actual improvement to the language?
CChris
|
Not Categorized, Please Help
|
|
