1. 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
>
>
2. RE: Rob list
Cuvier Christian wrote:
>
> >
> > 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?
I guess it depends on your definition of 'time critical.' Is a half
second ok when waiting for a database query to display? How about 5
seconds for the same query? These things often add up. When dealing with
non-trivial amounts of data, I believe that the performance of Euphoria
is important.
> > 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.
If you can know what all of your data is. As soon as you get user input
or read a file, you lose that predictability. Not to mention the headache
associated with being able to determine how any variable is modified. What
would you do with a complicated function that could return different
datatypes? What about variables declared as objects?
You probably start using the lowest common denominator, and every number
becomes a double, and you've killed performance in a new way.
Matt Lewis
