OpenEuphoria

Re: Homogeneous sequence

• Posted by Pete Lomax <petelomax at ?lueyo?der.co.uk> Aug 13, 2007
• 695 views

Robert Craig wrote:
> 
> This reminds me of a proposed extension to the type system
> that various people, including myself, have thought about before.
> It would be intuitively clear, and somewhat useful, to allow
> type declarations such as:
> }}}
<eucode>
>   sequence of integer x
>   sequence of object x
>   sequence of sequence x
>   sequence of sequence of atom x
>   sequence of my_user_defined_type x
>   etc.
> </eucode>
{{{

> 
When I last thought about this, I came to the conclusion that the above was
wrong. Specifically,

sequence of sequence of atom z

has two problems:
 1) minimal semantic meaning
 2) no way to perform the manual type check, unless you plan to allow:

if sequence of sequence of atom(z) then

As far as my logic got, I figured the *ONLY* place an "of" should be valid
is in a user defined type definition:

type set(sequence of atom s)
       return 1
    end type
    type set_table(sequence of set st)
       return 1
    end type

Limiting the number of times that "of" can be used to *ONE* should help solve
both the problems mentioned above, and allow sensibly typed work vars when
playing with individual elements of these things.

While I somehow doubt this will gain much in the way of popular support, I
remain convinced it is far superior while still achieving all the benefits you
outlined.

Also, "sequence of object" should imo be an outright compilation error.
That is what "sequence" already is and I see no reason to either perform a
squillion isObj() tests or permit the expression then optimise it away.

> I spent a lot of time thinking about this a few years ago.
Did you leave any design notes lying around?

>   * Newbies might be confused, and put off by all this, 
>     thinking it was somehow necessary to provide full and proper
>     types for everything.
Maybe not. It has been a while now, but on re-reading:
"To augment the predefined types, you can create user-defined types."
"For many programs, there is little advantage in defining new types"
"However, for larger programs, strict type definitions can aid debugging"

I probably mentally skipped that section on first reading anyway, but was glad
to know it was there.

It is usually a good idea to drum up the doc changes first of all, and I feel
sure you can find the words to reassure the newbie that they can keep it simple.

Regards,
Pete