OpenEuphoria

Re: Type - Start Again

• Posted by Pete Lomax <petelomax at blu?yond?r.co.uk> Aug 20, 2007
• 643 views

Salix wrote:
> 
> }}}
<eucode>
> type customer(sequence x)
> 	integer x[1] as id
> 	sequence x[2] as name
> 	sequence x[3] as address
> end type
> </eucode>
{{{

> 
> I would like to hear your opinion on the 
> simplification shown above. What do you think?
> 
I can accept that, with some qualifications (see below)

Peter Robinson wrote:
> Once you accept a declarative shorthand for boolean expressions, 
> the following is equally intuitive:-
>
> type ten_ints( sequence x )
>     length(x) = 10 – insert any boolean expression you want
> end type
>
> Since type blocks are just a series of boolean expressions, why not ASSUME 
> that in a declarative syntax?
But they are not. Types can be very useful in debugging, eg if I notice that my
program has crashed because something has set bCFwd[31][2] to -7, then I can find
where that happened by using a type, with any of:

if x[31][2]=-7 then return 0 end if
  if x[31][2]=-7 then ?9/0 end if
  if x[31][2]=-7 then trace(1) end if

Currently types, like functions and procedures, have implicit <locals> and
<code> sections. I can accept this be changed to <fields> <locals> <code>.
But I would not be happy with a change that meant type definitions could no
longer hold local vars and code.

CChris wrote:
> Looks nice, but the parser will have a terrible time with this...
It all seems pretty straightforward to me:

-- in type/routine definition (pseudocode)
    if <rtn type>=E_Type and <param type>=T_Sequence then
        -- process (optional) fields section:
        while isType() do
            nextToken()
            if tok[ID]!=<parameter> then
                -- complete first local var specially, since we accidentally
                -- just "ate" the sequence/integer/etc token [if needbe]
                exit
            end if
            expect "["
               ...
        end while
     end if
     -- existing handling for <locals> and <code> follows

In the same way that <locals> must be defined before <code>, keep it simple by
ruling that <fields> must be defined before <locals>.

The scope of id,name,address etc is a far trickier problem, imo. The only thing
I could suggest is have a look at the $ handling, however while mycustomer[name]
is fine, mycustomer[f(name)] would not be... Also, in

type address(sequence x)
    sequence x[1] as addr1
    sequence x[2] as addr2
end type
type customer(sequence x)
    integer  x[1] as id
    sequence x[2] as name
    address  x[3] as addr
end type
    ...
    .. mycustomer[<xxx>][<yyy>] ..
    ...

Then id,name,addr would be valid for <xxx>, but addr1 and addr2 would only be
valid for <yyy> if <xxx> was (?the literal constant?) addr, and of course all
invalid elsewhere on that line (barring another customer var subscript).

Oh (and this was going to be a short post), is this going to be annoying?

procedure showName(object x)
    if customer(x) then
        puts(1,x[name])
                 ^ invalid

Of course when someone comes and optimises their code it must still work:

procedure showName(object x)
integer cx
    cx=customer(x)
    if cx then
        puts(1,x[name])

Now /that/ is something a human sees well but gives a parser nightmares 

This is also getting perilously close to puts(1,x[name]) implementing late
binding, but for that you would need to declare customer as an OO class.

In fact on that note......   

> This way we would extend types to _also_ include heterogeneous sequences, 
I would imagine that

type x(sequence of <type> y)

means it cannot have a fields section, a simple "and not <someflag>" after the
E_Type test above. Of course you cannot have a fields section on a type declared
as integer, atom, or object (assuming we get the ret 0 fix) either.

Regards,
Pete