Re: Structures; etc.
Gentlemen,
This conversation is getting close to a religious discussion. There must be
some happy medium. I thought I'd never hear myself say it, but I'm starting
to sympathize with Rob's whines about minimalism. I think that the minimum
set of changes should be implemented that will make all the things proposed
in these posts possible. I really like Mr. Cuny's description of classes and
instantiation for OOP, but I think that most of it could be accomplished
through pre-processor if Euphoria had adequate namespace and structure
capabilities with built-in type checking for sequences.
Classes and Object orientation do not answer the need for structures.
The one thing that makes structures absolutely necessary is the
existence of that world of externally defined data that Euphoria has no
control over. Objects, sequences, atoms and integers are arguably
sufficient to describe any type of data in a world that only includes
Euphoria, but that is not the world that we have to work in. At some point,
we must be able to control the physical presentation of data down to the
bit, bit order, byte, double byte or word, double word, paragraph, etc. level
reliably or we will be peeking and poking or assembling and disassembling
data forever, instead of working with it. If we wish to prefix these with the
term external or foreign, then do it, but we must have these definitions.
In addition, structures do not have to be fixed, only their descriptions.
Variable length fields, nested structures and occurrences will allow the
description of almost any form of well defined data. If null structures can
be defined, then instantiation can be had through simple assignment of
a null structure to an Eu object. If you don't mind the memory overhead of
a full prototype, then null structures are not necessary(I don't recommend
this because structures can be quite large). I believe that structure
definitions themselves can be sequences interpreted by Euphoria as an
internal type. Included in those sequences can be initialization logic
triggered at definition for regular structures and at assignment time for
null structures. I would very much like a syntax something like an example
that Irv Mullins sent me that looked like this:
PHONE_LIST = Customer[NAME,PHONE,PAST_DUE90]
where Customer is a predefined structure and the fields are not contiguous
and PHONE_LIST is a sequence or object. The only danger in this construct
is that some will say that all we need for this is constants which will lead us
right back around into namespace problems. They may have a constant
value, but they cannot be explicit constants without all the many problems
that have been pointed out by myself and a dozen other people over time.
The need for internal type checking on defined type fields in at least
Euphoria internal structures is a performance necessity.
For performance purposes, arrays whose form if not length can be fixed are
the last major area of need. Without these, many things become subject to
a huge amount of explicit overhead that means little, contributes nothing to
the programming process and is hugely inefficient. Arrays are a subset of
structures or sequences and offer so many opportunities to make time
saving assumptions in the interpretation process that it amazes me that
they haven't just jumped in of their own accord.
Add these to the prefixing of the namespace of includes and a more
generalized and flexible calling capability and all else can be accomplished
with preprocessors and libraries.
Everett L.(Rett) Williams
rett at gvtc.com
On Sun, 30 Jan 2000 16:58:10 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>On Sun, 30 Jan 2000, JJ wrote:
>> EU>On Sun, 30 Jan 2000, Irv wrote:
>
>> EU>You can see that user-defined types are useless except for debugging
>> purpose
>> EU>as the overhead kills any performance whatsoever. This is for a single
>> type
>> EU>check. I haven't even tried nested type checks. Any pre-processor would
>> eith
>> EU>have to let everything go untyped, or rely on the type() function. Neither
>> i
>> EU>acceptable. This functionality needs to be built into the language itself.
>>
>> EU>Irv
>>
>> How would building object-orientation into the interpreter make this go
>> faster? A pre-processor could be smart, and not do unnessicary type
>> checking. For example:
>
>No one said object-orientation would make it faster. I don't even like
>OOP. What I said was, if Euphoria typed checked variables
>_wherever_ they were, using internal type checking functions, we would gain
>safety with very little loss in speed. This has not related to OOP.
>
>> type sequenceOfIntegers(object x)
>> if sequence(x) then
>> for i = 1 to length(x) do
>> if not integer(x[i]) then
>> return 0
>> end if
>> end for
>> return 1
>> end if
>> return 0
>> end type
>>
>> class MyClass
>> sequenceOfIntegers seq1
>> sequenceOfIntegers seq2
>> sequenceOfIntegers seq3
>> sequenceOfIntegers seq4
>> sequenceOfIntegers seq5
>> end class
>>
>> MyClass instance
>> instance.seq1 = repeat(0,100000)
>> instance.seq2 = instance.seq1
>> instance.seq3 = instance.seq1
>> instance.seq4 = instance.seq1
>> instance.seq5 = instance.seq1
>> instance.seq5[50] = 1000
>>
>> A smart pre-processor could optomize see that:
>> 1. When instance.seq1 and instance.seq5[50] are assigned, there is no need to
>> check everything else.
>
>A smart pre-processor might see it, but it couldn't do anything about it
>without passing it thru your type() function. If user type checking one value
>takes 9x as long as a similar built-in integer check, just imagine how long
>that nested check it going to take. Worse, what if the array is not of a
>built-in type - perhaps it's an array of coordinates, for example. Then your
>type check loop has to call _another_ user defined type check. Nap time!
>
> > 2. When instance.seq2-5 are assigned,there is no need to check them
>> because instance.seq1 is the same type and they're ok >
>
>Nope. Suppose I change something in seq2. In fact, why would I even declare
>5 sequences of integers _unless_ I planned to change the contents? Might as
>well use one. It's when assignments are made that the type checking must come
>into play.
>
> > In your example, a smart pre-processor could see that 5 is a byte,
>and therefore x doesn't need to be checked 10000000. In fact, an even
>smarter pre-processor could optomize the code to: >
>> byte x
>> atom start
>> start = time()
>> x = 5
>> ? time()-start
>
>Sure. But what if that line was x = z ?
>z might be almost anything. Who knows, each time it might be different.
>Unless your pre-processor is psychic, I don't think it's going to be able to
>simplify things very much.
>
>Irv - busy inventing the Prophetic Pre-Processor.
|
Not Categorized, Please Help
|
|
