RE: Rob list
> Subject: RE: Digest for EUforum at topica.com, issue 5758
>
>
> posted by: Matt Lewis <matthewwalkerlewis at gmail.com>
>
> Cuvier Christian wrote:
> >
> > >
> > > > Also, isn't it simpler to extend the semantics of
> > > > "integer" to cover what ALL language around do, ie machine
> > > > size integers (32 or 64 bit according to host hardware)?
> > >
> > > I have no idea what integers have to do with non-blocking
> API calls,
> > > but Euphoria's integers only use 31 bits, because (effectively)
> > > there is a bit that says "this is not an integer, it's
> > > a pointer to a larger object". Most other languages don't have
> > > dynamic "larger objects" like Euphoria's sequences.
> > >
> >
> > Sorry, was mixing this issue with another odll (thought he
> wrote it too)
> > which alows to use 32-bit integers when talking with
> dll/apps made with sany
> > other language.
> >
>
> No, this was something I'd done. It doesn't require a dll,
> but just some
> added euphoria code and a little preprocessing of the
> translated c files
> before compiling.
>
> > Most other languages have dynamic objects like sequences
> with various names,
> > all those that are object aware at least. (note: I hardly
> ever used Basic) I
> > admit that joining sequences is easier in Eu than in these
> other languages,
> > but that's only one strong point versus many others.
> > I use "object aware" for languages that are hybrid like C++
> or Delphi, as
> > opposed to "object oriented" ones like Java or Eiffel.
> >
>
> As someone who's but a bit of thought into this subject, I
> think you'll
> find that there's not likely a faster way to implement
> Euphoria's datatypes.
> Rob's found a solution that allows him to quickly determine a
> value's type
> with a minimum of overhead.
True, it may be the quickest. Is this really important outside of time
critical apps, on nowadays machines?
> Any 'object aware' language will
> likey either
> add lots of overhead (i.e., slow) or be very strictly and
> statically typed
> (and kill a lot of what makes Euphoria worthwhile).
>
The crudest way to implement this I can think of is adding a single type id
to the object in-memory representation, and having a compile-time generated
table listing all possible type conversions and routines to use to this
effect, table to be looked up on each assignment. Is this what you call
"lots of overhead"? And this scheme is clearly unsophisticated. The compiler
can remove most of the lookups, hence making the overhead pretty slim.
Static typing is not necessarily as contrived or strict as it is in C++,
which is admittedly an acute pain sometimes. I have started writing stuff in
Eiffel over the last months, and found it rather amenable. Sure, you have to
specify whether you wish to in/out-put an integer, a real or a string. And
in some cases you have to write an explicit convert clause to avoid the
compiler moaning about mixing integers and reals. Since this sort of basic
output represents 0.5% perhaps of what I write, it doesn't bother me too
much.
> That said, if you can come up with another solution that can
> balance these
> issues (speed vs overhead) I'd be interested to hear it. Of
> course, once
> Euphoria goes 64 bits, we could probably make the case for other new
> datatypes.
>
A first solution would be to redefine "integer" to represent what everyone
would expect, hiding behind the scene that integers which use the 31-th bit
are internally represented as doubles. This would make migration and
interfacing easier without much trouble.
CChris
> Matt Lewis
>
>
|
Not Categorized, Please Help
|
|
