Re: Ideas for next Eu
On Wed, 10 Nov 1999 14:25:22 -0500, Irv Mullins <irv at ELLIJAY.COM> 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()
I THINK that this only works when [line...column] are positioned properly
in the sequence MyWindow. The case that I was driving at was the one
where get_position_xxx() returns a sequence that doesn't start with
line and end with column and I would still like to be able access line and
column in that and another screen whose attributes have been gotten
through the same function. Regardless of the position of line and column
in the resulting sequence, if they are described in a proper structure, I
can refer to them by xxxx.line, xxxx.column, yyyy.line and yyyy.column
without fear of stepping on any constant or variable that may be defined
elsewhere. And I don't have constants proliferating all over the place and
taking up namespace that should be cleanly structured not to need them.
>
>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.
My vote is that any solution that depends on constants is a chimera that
solves nothing and takes up memory for nothing.
>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.
Then why suggest it when you know it can't easily work in any large
program?
>
><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}
Actually not. The temporary sequence (this,that,theother} only exists on
that one line for the purpose of using the current assignment rules to
initialize it. When the line ends, the sequence dissolves back into the
individual integers from which it was temporarily formed.
>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}
Ugh! You just created a completely new syntax that is both large and
cumbersome. The real power of the sequence assignment shorthand
can be used here to initialize the variables while adding no error
prone assignment lists that require proper left to right matching
to get the initializations right.
>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.
Why take up the space until the item is needed when the only thing needed
is not data, but structure.
>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)
I just knew that I would get in trouble by trying to use as an example
anything in a language that I don't program in 
Sorry to be unclear.
That is why I used the adjective "null" for the sequence descriptor. Cancel
anything that I said about "void" as being stupid and random. HOWEVER,
the null sequence/structure that I described does not have any values
assigned in it. It is only a template for the assignment of those values
when the structure is instanced. The instancing of the structure will
trigger the running of the initializations and the assigning of the
names modified by their sequence variable.
>> 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.
Again, I apologize for the code, but the forms in it apply whether I
WANT to compare all the values between line and column or not.
I can still use your form if I want to compare all those values and
yes that is nice.What if the values in between line and column
are not being kept in synch. Again, please do not confuse the
specific example with the method proposed. Nothing that is will
be lost, but the ability to refer in an unambiguous manner to
individual data items in a sequence/structure is not currently
possible without the above excoriated(by both you and me)
constant technique. I don't wish to lose any of the current
capabilities.
> <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.
Agreed in principal, but not in fact. Euphoria does not control the
data generated by the rest of the world, regardless of how logical
it currently is to only use 32 bits for everything. When a processor
is having to shove it around, many times it uses bits for flags. If
we would like easy access to the assembler world on various
processors, bit, byte and double-byte types will vastly simplify the
process and the code. In addition, a huge amount of the data in the
online transmission world is full of bits and bytes, because network
speeds are not likely to soon approach processor speeds and
throwing in unused filler to make everything a 32 bit word would
drastically slow down routing, transmission, etc.
>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.
Those data types currently cause huge overhead in programs that
make any significant use of them...to the point that type checking
must be turned off in most production programs that have them. We
lose one of the real powers of Euphoria in more dynamic programs
because we refuse to recognize these common data types in any
form.
I am effectively proposing that, by limiting those data types to an
"external" sequence type and putting the conversion into the assign
statement, type checking can be preserved and Euphoria can
continue in large part, unsullied. It also allows Euphoria itself to
take care of things like bit order and sign handling differences found
in different machines.
>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
In summation, we differ mostly in degree rather than kind. I hope I have
made my proposals a little clearer in this post. I would especially like
your and anybody else's opinion about the way I propose to assign and
initialize structures at the point of instance. The syntax of individual
items is not nearly as important. IMO, there is some real power in
this way of naming and assigning at the point of definition of "real"
data. It should also improve garbage collection, by putting the creation
of data closer to the code that uses it.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
