Re: Re[2]: (Another) (small) Eu 2.5 feature request.
> Not quite sure why I see that as critical, I suspect it is a
> combination of the difficulty of implementig"sequence of"and the scope
> problems of PersonalName, unless it can *only* be used as a short
> immediate subscript on a customer var, which makes sense to me..
"difficulty of implementing "sequence of" "....
No!
It's not difficult.
If you check back through the list, I've put together lots of stuff on
"of", including a manifest (below), and a demo
(http://users.secsme.org.au/~prbarnes/misc/oth/of.zip)
It's very fast, much much faster than manually checking everything.
Rob said he didn't want to implement it because (paraphrasing, correct
me if I'm wrong Rob) type checking wasn't considered to be part of
euphoria, except for debugging, and any enhancements to it would
confuse newbies.
> Whatever, I for one would certainly not attempt all of this in one
> hit, related as it is or not! It is far from easy to see how best to
> do it.
Well, I believe we need a better type-checking system before we can
attempt to do any structures...
If the "of" system was implemented first, that would benefit many
people... even those not using structures. The structure system
couldn't be implemented on its own.
Y'know, it's wonderful that a sequence can hold anything... it's much
better than C-style arrays.
However, can *anyone* show me a program where they've used a sequence
variable that was:
1. Large.
2. Completely non-homogenous. That is, there was no underlying
structure to the sequence *at all*...
I find that I only have two kinds of sequences.
Small ones - Holds something like a structure. non-homogenous, but
well-defined (ie first element is a XYpos, 2nd is a color, third is a
picture handle, etc.)
Big ones - Holds multiple small ones. Homogenous, because every
element has the same (small ones) structure.
I've never had to break from this. The "of" keyword could greatly
benefit me (yes, me me me) but I suspect many others too...
--
MrTrick
1.
The keyword 'of' is used in the Euphoria language to apply additional
restrictions to a sequence. The 'of' declaration is ONLY allowed
within a type declaration, in the form:
type $base_type ( sequence of $element_type )
--###type body###--
end type
(? I figure this is a good idea, so that the typing is centralised ?)
2.
the left hand of the 'of' MUST be sequence.
3.
There are no special restrictions on $element_type. It may be a
pre-defined or a user-defined type.
4.
The allowable functionality within the ###type body### is restricted
when the 'of' keyword is present in the header. (?Should we disallow
access to external functions? Perhaps. ?)
4a.
The ###type body### should not access any of the elements, but only
check aggregates of the base element, like length. (?If any element
is accessed, a warning should be issued that the type may cause major
performance issues. This could be useful for a type that cares about
the sum of it's elements?)
5.
$base_type and $element_type are not both incurred for every change.
Refer to this table:
variable is assigned to another variable ( x = y ):
* If y is of the same type, no checking is done.
* If y has a different $base_type, but the same $element_type, check
only $base_type.
* If y is of a completely different type, check $base_type, then check
$element_type against each element of the variable.
variable is assigned to a literal ( x = {3,5,1,7}):
* If {}, only check $base_type.
* Otherwise, check $base_type, then check $element_type against
each element of the variable.
variable is assigned to a function return ( x = doStuff() ):
* Behave according to the data type that was returned.
variable is assigned to the result of a logical operation
( x = {y[1]} & x[2..length(x) - 1] & {1} ):
* First, check the $base_type
* If a slice was taken from the same data type, then the elements
are known to be valid. Do not check those elements.
* If a component was not the same type or a literal, check the
elements in that type.
variable has an element or elements changed
(x[1] = y[length(y)] or x[2..4] = {7,1,3}):
* If the new value for the element already has the same data type,
no checking is required.
* If the new value has a different type or is a literal, check
that element(s).
* (?As no changes would have occured to the aggregate properties
of the $base_type (length), don't check the base?)
Example:
type positive_int (integer t)
return t >= 0
end type
type index ( sequence of positive_int s )
return 1
end type
index x
x = {6} -- checks base, and first element
x &= 4 -- checks base (cause length has changed) and new
-- element, but not first
x[1] = 5 -- checks element 1, but not base (length has not
-- changed)
x[1..2] = {4,1} -- checks element 1 and 2
x &= {10, 0} -- checks base, and the new elements, but not existing
x = y -- If y is an index, no checking required, otherwise
-- check whole sequence.
x = y[2..3] & {1} & y[5..length(y)]
-- If y is an index, then no checking on that part of
-- the variable. Check base, and check the to-be-new
-- elements that are not index elements already.
x = {0} -- x is completely reassigned. If to a literal, check
-- the whole type.
x[1] = -1 -- error here (element 1 is checked, and fails.)
6.
Some more optimisations can be made.
* If a type declaration does nothing (just returns 1) the interpreter will
consider that type to be the same as that of its argument.
* Upon parsing, if multiple types (base or element) have the same profile
(same arguments, same bytecode in ###type body###) they will be considered
to be the same type.
7.
Implementing these changes would probably need to be combined with
making the regular types more robust - If an atom type is checked
against a type that has a sequence or a sequence of %% argument,
fail needs to be returned rather than crashing.
(?Perhaps also look at short-circuiting return values?)
8.
If a subscript of a "sequence of $element_type" type is taken,
the subscript has the $element_type type.
9.
If a slice of a "sequence of $element_type" type is taken, each
element still retains it's $element_type.
10.
Built in functions, where possible (append, prepend, etc), will return
the same type as was passed to it.
11.
???Any more suggestions???
|
Not Categorized, Please Help
|
|
