Re: "OF" in types...
------------------------------------------------------------------------
magnae clunes mihi placent, nec possum de hac re mentiri.
------------------------------------------------------------------------
MrTrick
>From: Pete Lomax <petelomax at blueyonder.co.uk>
>Subject: Re: "OF" in types...
> >Any comments on this yet?
It's latin, you troglodyte.... Although it's a contemporary reference.
> >The 'of' declaration is ONLY allowed within a type declaration,
>Any particular reason why?
>type x(sequence of z)
> return 1
>end type
>On a previous post you said that a simple return 1 could be ignored.
>That would make x y and sequence of z y exactly the same.
This was in reaction to the recommendation that no "sequence of <udt1> of
<udt2> of .... of <udtn>" be allowed.
If "sequence of <udt>" is allowed anywhere, is it allowed within the type
declaration, leading to the above problem.
>4/4a. I think you are on the right path there, needs a bit more
>clarification, and dare I suggest examples of good and invalid?
>It shouldn't be "disallow"; it should issue warnings (unless without
>warning is in force around the type definition) and not be "fast" type
>checking.
That sounds good.
>5.2 if assigned to a literal and {}. You are wrong there. a literal is
>an object, it always needs full type checking (and it is often more
>important than run-time type checking, to make sure you start off on
>the right foot).
Ah... I said full type checking. That's what it describes.
If the literal is empty, there are no elements for it to check. This should
mean that it doesn't have to check those non-existent elements :o)
>5.3 Ditto, functions only ever return an object. Of course a function
>can return anything, you can easily write a function that (randomly)
>returns an integer, float, or a sequence: you just *have* to treat
>function returns as type object, life gets too difficult otherwise.
Well, no, I'd say that this is a very necessary optimisation... Say you pass
a large data matrix to a function, that slightly changes the matrix and
returns it:
function addElement(matrix x, matrix_element y)
return x & {y}
end function
matrix x
matrix_element y
x = getExistingElements()
y = newElement()
x = addElement(x, y)
Because we can see the type of the returned value in the return line, we
know that elements 1 to length(x) - 1 of the matrix are valid. It's only the
new element(s) that needs to be checked, and in this example, it's already
known to be a matrix_element, so it doesn't need checking either.
It would behave as if the "return ####" was like the "x = ####". Make
sense?
>5.4 not a logical operation but a concat()?
Oops, semantic error
>6. I retract this. There is no way to make badly written types fast.
>Instead, I want to be told how to write fast type checking.
>You can, of course (by enclosing in "without warning") still write
>slow type checking, I want to know how to write type checking which
>can be left on in production code, ie that does not kill performance.
>Eg a type which maintains a sum is "badly written".
Yup, that's good.
>7. Derek quashed this?
Well, the problem is here:
type 1d_array(sequence of int x)
return 1
end type
object x
x = 15
if 1d_array(x) then
puts(1, "X is a 1d array")
else
puts(1, "X is not a 1d array")
end if
If this behaved as types do now, then the program would crash, because
"sequence of int" is not satisfied in the passed parameter. That's why I
think it needs to shortcut back 0... We can't really write:
type 1d_array(object x)
if sequence of int (x) then --doesn't work, spaces in type
return 1
else return 0
end type
>I am slightly worried you are overly concerned with checking the
>"base", in my mind checking fewer elements is the key? The more I
>think on this, everything should be done _via_ the base, just passing
>the minimum number of elements...
>Also, for nested types, and subscript assignments, invoking the type
>checking "at the right level and no higher".
Well, as I said, the "base" checking is used as a type_def equivalent in
most cases, so we don't have to keep writing sequence of <udt>. If it was
only a return 1 then that would be fine.
The only reason for having a base type was to allow restricted-length
sequences... For example, you might be concerned about interfacing something
to some C code, where it is known that there is only 255 elements allowable
in a char array, for example.
In almost all cases the type checking of the base is skipped, because it's
just a return 1.
------------------------
MrTrick
|
Not Categorized, Please Help
|
|
