Re: [LogoForum] Re: item & setItem bitwise?

The message below is being cross-posted from LogoForum.


So when you say something like "i8" you're talking
about the representation, and ...

... and that's exactly when you shake the worm-jar in your left hand while
holding its screw-lid in your right hand. :) :) :) I don't think internal
representation should be encoded in the "visual representation" of the
datum. At least in Logo.

And focusing back on the "i8" notation, here is why I do not like it:

[1] It applies only on constants. If you want to pass a 32-bit integer
value of a constant you put suffix "i32". But what it this value is not a
constant but in a variable named X? Will the notation be :Xi8? Of course
not! So in this cases there should be another way to make the conversion
from :X that hold a Logo numeric atom into a 4-byte integer:
- if this way is implicit (e.g. automatic typecase conversion done
internally by the interpreter), then it will also work on constants
without "i8"
- if this way is explicit (e.g. a system function that handles
conversions), then this function can be applied on constants too

As a result, in both cases "i8" is not needed.



[2] Having "i8" as a suffix will make trouble to the interpreter. Here is
one example:

make "s [3i8 10]
make first :s first bf :s
print :3i8

This example works fine in all Logo implementation which I tested, but
imagine that 3i8 is represented internally not as a Logo atom but as an
8-bit value. How this value will be used as a name of a variable? If the
interpreter will make an automatic conversion between Logo atom and C
datum then it can make this conversion in all other cases, so "i8" is
again not needed.


[3] If you run MAKE "A 3i8 what will be the internal representation
of A?
- if it is a Logo atom, then conversion is already done and "i8" was
not needed, and when you use A to communication with external API a
back-conversation must be done...
- if it is a C datum, then how would (SIN :A) work? And how will A
remember that it's value is a byte, not an atom?



You see that although "i8" solves *some* problems with interfaces, it
introduces *some* others. May be the easiest way (for you and me) is to
wait for Andreas to implement it and then hunt for counterexamples.



The *best* thing is for everyone to program in late-binding languages and
not have to deal with bit formats at all. Meanwhile, though, that's the
problem that's on the table.

Does this mean that because "i8" is the only suggested solution you become
reconciled with it? I don't like "i8", but I'm optimistic that there is
another (possibly better) way.

You may wonder why I'm so active about this topic. The reason is that
Lhogho is compiler => Logo programs are supposed to run much faster when
compiled by Lhogho => users will start to use more advanced technology
(especially if these users are ex-C users) => they will need a direct
interface to various non-Logo APIs => most likely I will have to solve
this problem in Lhogho.

Right now I have no solution, but I do not give up that easily, because
Lhogho will need this more than any other Logo.

So I'm really interested in Andreas' research in this area. The more ideas
we gather the bigger the chance to find a good solution. Andreas, I'm
waiting for your comments too. Structs will definitely add value to Logo,
but do you really need the "i8" notation? Can you do conversion
automatically, so that users will not bother with "i8"?



-Pavel


LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

.

Relevant Pages

  • Re: Adding Older Versions of GCC To The Tool Chain ... safely?!?!
    ... There is by definition no such thing as 'an unsigned overflow', ... the bits of the object representation ... for conversion to an unsigned type to be performed on mathematical ... If an exceptional condition occurs during the evaluation of an ...
    (comp.os.linux.development.apps)
  • Re: Question re. integral promotion, signed->unsigned
    ... >>Why is it OK to reinterpret a signed integral type as ... > but such a conversion isn't well defined if the value of the unsigned ... regardless of the representation of negative values. ... > While this conversion is well defined and yields the same result, ...
    (comp.lang.c)
  • Re: Singles to Doubles
    ... number then we could provide some optimisation to the binary conversion ... If you're saying an internal representation of 1.11 should be ... the external representation arises, ... whether one is extending zeros in the external or internal representation. ...
    (microsoft.public.vb.general.discussion)
  • Re: canonical conversion of float/double to strings
    ... decimal string which, when converted back with Double.parseDouble, ... the specification of that conversion is constrained so ... The specification mostly states that the decimal representation ... specification which is considered as better in the comments of the bug ...
    (comp.lang.java.programmer)
  • Re: Casting an array to integer type
    ... its value when the sign bit is clear must be zero. ... succeed, in any of the three representation schemes, ... the result of the conversion is a trap representation, ... yield a trap representation and produce undefined behavior; ...
    (comp.lang.c)