1. "OF" in types...
I've taken input from people regarding this thread, and placed it here:
http://users.secsme.org.au/~prbarnes/misc/oth/type_of.txt <-- Draft spec
(Rob, whaddaya think?)
Please comment.
Some sections are not yet concrete, they are marked with (? ?)
Thanks
MrTrick
2. Re: "OF" in types...
On Thu, 03 Jun 2004 08:23:18 +1000, Patrick Barnes
<mistertrik at hotmail.com> wrote:
>Any comments on this yet?
>------------------------------------------------------------------------
>magnae clunes mihi placent, nec possum de hac re mentiri.
Martin Clunes ate my placenta, therefore I became retarded?
>------------------------------------------------------------------------
>>http://users.secsme.org.au/~prbarnes/misc/oth/type_of.txt <-- Draft spec
>>Please comment.
>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.
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.
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).
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.
5.4 not a logical operation but a concat()?
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".
7. Derek quashed this?
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".
Pete
3. Re: "OF" in types...
Patrick Barnes writes:
> Any comments on this yet?
> Good? Bad? Ugly?
Thanks for your proposal.
I've saved it in my suggestions folder.
As I said, I carefully analysed something like this
a few years ago. I haven't ruled it out, but I will not
be implementing this for 2.5, so I don't want to spend
any time on it now. I can discuss your proposal after
2.5 is out.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: "OF" in types...
>From: Robert Craig <guest at RapidEuphoria.com>
>Subject: Re: "OF" in types...
>Thanks for your proposal.
>I've saved it in my suggestions folder.
>As I said, I carefully analysed something like this
>a few years ago. I haven't ruled it out, but I will not
>be implementing this for 2.5, so I don't want to spend
>any time on it now. I can discuss your proposal after
>2.5 is out.
>
>Thanks,
> Rob Craig
That is fine, I know you're close to releasing 2.5 now.
Could we have a page on rapideuphoria somewhere that shows the features you
plan to implement in the next version of the language (So currently for
2.5), and a list of features that are being considered for unspecified
versions beyond that? It would make it easier for us to see what you are
planning with the language, and make appropriate suggestions.
MrTrick
5. 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
6. Re: "OF" in types...
On 3 Jun 2004, at 12:26, Patrick Barnes wrote:
>
>
> ------------------------------------------------------------------------
> 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.
Yeas, quis homines huiusmodi intellegere potest?
Kat
7. Re: "OF" in types...
>From: Kat <gertie at visionsix.com>
>Subject: Re: "OF" in types...
>On 3 Jun 2004, at 12:26, Patrick Barnes wrote:
> > It's latin, you troglodyte.... Although it's a contemporary reference.
>
>Yeas, quis homines huiusmodi intellegere potest?
Actually, I don't know any latin. :oP
MrTrick
8. Re: "OF" in types...
Patrick Barnes wrote:
>Dear Rob
<blah blah blah>
>plan
<blah blah>
I think you get the idea 
))
Pete
9. Re: "OF" in types...
On Wed, 2 Jun 2004 21:56:06 -0500, Kat <gertie at visionsix.com> wrote:
>On 3 Jun 2004, at 12:26, Patrick Barnes wrote:
>> magnae clunes mihi placent, nec possum de hac re mentiri.
>> It's latin, you troglodyte.... Although it's a contemporary reference.
>Yeas, quis homines huiusmodi intellegere potest?
Alas, even moderately intelligent humanoids shame us?
