Re: Ideas for next Eu
On Wed, 10 Nov 1999, you wrote:
> On Tue, 9 Nov 1999 16:40:10 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>
> >Gabriel Boehme wrote:
> >
> >> {line, column} = get_position()
> >
> >Yes!
>
> Isn't this just the latest thread of the namespace, structure discussion, just
> an
> elaborate dance around the need for structure naming? If "line" and "column"
> are part of something that is 40 or 50 or a hundred items in size and I would
> like
> to refer to them by name rather than by x[23] and x[77], maybe with x.line
> and x.column, don't we need to be able to?
Right now, we can write this as:
MyWindow[line...column] = get_position() or as
MyWindow[location] = get_position()
Unfortunately, this is based on having declared constants for line, column,
and location previously, which can be a real pain when you're dealing with
a large number of items - an even bigger pain each time you modify the
"structure" - and downright unworkable if you have more than one object
which has need for a "line" and a "column" member.
A second drawback is that it is entirely possible to assign
MyWindow[location] = "Jersey City", which is likely to make the rest of your
program very unhappy, but won't provoke any error message at the point of
assignment.
<snip>
> Nothing in the world should keep the current Euphoria definition from
> working, but I would like to add this to it.
> null sequence xxxx{
atom x = 0,
atom line = 0,
sequence y = "Hello World",
integer {this, that,theother} = 1, -- to preserve current syntax
-- and to easilydefine
more
-- more than one at
atime
atom column = 0,
atom z = 2}
> Note the temporary sequence used as shorthand. By your rules, this would
> result in a temporary seqence that looks like this.
> {x,line,y,this,that,theother,column,z} = procx(mumble)
For accuracy, it should actually look more like:
{ x,line,y,{this,that,theother},column,z }
which preserves the internal sequence that is made up of {this,that,theother}
Your syntax needs to be changed slightly if we want to call this
sequence by name:
sequence things {integer this, integer that, integer theother} = 1
or perhaps less confusing:
sequence things (integer this, that, theother} = {1,1,1}
I certainly like the idea of creating and initializing a "structure" in one
step. It adds clarity and shortens the code.
> -- use void definition from above
> sequence yyyy instance xxxx -- which would create and initialize the seqence
> sequence zzzz instance xxxx -- another sequence created and initialized
> yyyy = procx(virtual_screen1)
We can already do this, by simply initializing the first
sequence, and then declaring the following sequences like so:
yyyy = xxxx
zzzz = xxxx
The drawback to this is, since we can't "type" members of a sequence at
present, there are no "types" to pass on to the new sequences either, just the
contents.
You'll have to explain your use of "void" and "null" here. How can a variable
be "void" ? C has void function returns, which is a clumsy and error-prone way
to make up for the fact that sometimes calls are made to routines which do not
return any value. Other languages just call these "procedures" and eliminate
possible confusion.
C also has null variables (variables pre-initialized to "nothing", which is
not what you're showing above, as you have assigned some value to each of them)
> zzzz =procx(virtual_screen2) >
> if yyyy.line != zzzz.line then
> .... we are not synchronized ...etc..etc.
> elseif yyyy.column = zzzz.column then
> .... we are synchronized...etc....etc.
> else
> ....... we are not synchronized....etc. etc.
> end if
Of course, we can do that now, as well, but in a much neater form:
(Again, only if we have declared line, column and location beforehand:)
if equal(yyyy[location], zzzz[location]) then we_are_synchronized....
alternatively:
if equal(yyyy[line..column], zzzz[line...column]) then we_are_synchronized......
These one-liners compare _all_ the entries, no matter how many, between line and
column (or contained within the sub-sequence "location") at one time, which is
less work and more understandable that the if ....elsif .... code above.
<snip>
> When Euphoria really grows up and finds some way to deal with externally
> defined data structures,
> then we will get some kind of bit, byte, and double
> byte definitions to work with. By allowing named structures with these data
> types, and enforcing
> their use, we can isolate Euphoria from the worst of their
> effects. For example, Euphoria can force assignment of bits, bytes and double
> bytes to atoms, integers, etc. before they can be used elsewhere in code in
> the same way that variables are forced to be initialized before they are used.
A plethora of data types has little real importance anymore. There's enough
memory and disk space available so that we can simply use 32 bits to store a
boolean if we want to. Who cares? Keep it simple - Euphoria doesn't need to
look like C or Pascal, with dozens of type casting functions to convert between
bytes and words, etc. These are the kind of things that often make up several
hundred lines of a thousand line program.
If for some reason we really need to ensure that a value will always fit
into a "byte", or a "word" , we can define our own "byte" or "word" type with
three lines of code. So, there can be as many self-proclaimed data types as one
wants to fool with.
On the other hand, it's really sad that we lose all ability to type check
assignments to all user-defined and built-in types as soon as we store the
data into sequences. That's why we need a "structure" which allows us to
declare a type and a name for each member of that "structure" ,"sequence", or
"object", whatever one wishes to call it, and have both the type and the name
follow that member wherever it goes.
Regards,
Irv
|
Not Categorized, Please Help
|
|
