Re: direction
Robert Craig wrote:
>Lee West writes:
>> Thanks for responding... You didn't answer one of the
>> most repeated questions though. What about adding
>> true record structures of the type found in C/C++ and Pascal?
>> If not, could you give a brief explanation?
>
>This is exactly the type of question that I try to avoid.
Just because the problem is difficult doesn't mean that it
should be avoided. It certainly isn't trivial or somebody's
cool idea.
>There are two types of structures that people want.
>The first is a Euphoria structure that holds Euphoria
>data types. The second is a C structure that holds C
>data types. The C structure would be aligned in memory
>exactly as C requires.
Of course it would since it would probably be using a structure
provided from another program written in C or one of the many
programs that use C data structures.
>The problem with the first is that it takes a language
>that's elegantly based on two data types: atom and sequence,
>and it jams in a third.
The fixed sequence with known element types is in reality a subset
of the general set of atoms and sequences, not an addition to it.
It offers some real opportunities for optimization of a lot of otherwise
simple problems that are unreasonably hard to approach in Euphoria
as it stands.
>The problem with the second is
>that it forces Euphoria to suck in a lot of knowledge
>of C, and possibly even a particular C compiler, since
>there is no universal standard for alignment of C structures.
>My intention was that certain people would interface with C
>using peeks and pokes and the rest of us would simply
>call Euphoria "wrapper" routines and not have to worry about it.
>To a large extent that is what is actually happening.
I don't accept your premise that there is significant variation in
alignment in C structures in the major dialects. Even assuming
that you are correct, you can then give us structures that can
be adjusted for different alignments. It wouldn't be hard to provide
a structure description capability that could handle any
combination of bit, byte and higher data types.
>You could also achieve structures by creating classes with
>data members, but object-oriented features would be another
>big blast of added complexity that I'm not ready to accept yet.
If the tools of namespace and structure and modularity are
provided, it appears that there are sufficient volunteers to close
the OOP circuit for those that want it. I don't, but many may.
>I've never been satisfied with any proposals
>for either of these structures, but if someone comes up with
>a *concrete* proposal that I like, I'll implement it.
>Until then, I probably won't comment any further on it.
>
You'll be glad for us to do the work and show our stuff to you,
but your cards all remain hidden. Something seems a bit
unbalanced there. Even Linus doesn't try to pull that one off,
and he probably could.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
