OpenEuphoria

Re: Homogeneous sequence

• Posted by CChris <christian.cuvier at agricu?tu?e.gouv.fr> Aug 13, 2007
• 694 views

Pete Lomax wrote:
> 
> CChris wrote:
> > 
> > > }}}
<eucode>
> > >     type set(sequence of atom s)
> > >        return 1
> > >     end type
> > >     type set_table(sequence of set st)
> > >        return 1
> > >     end type
> > > </eucode>
{{{

> > > Limiting the number of times that "of" can be used to *ONE*
> > 
> > I must be having a nightmare.
> > So you never had to deal with sequences of strings
> You are misreading me. I am saying "force the programmer to give each level
> a plausible name". You can daisy-chain 37 udts together if you wish.
> 
> In the above, a set_table is a sequence, each element of which is a set, where
> a set is a sequence, each element of which is an atom. For your example you
> could code:
> }}}
<eucode>
>     type char(integer c)
>        return c>=32 and c<=255
>     end type
>     type line(sequence of char l)
>        return 1
>     end type
>     type file(sequence of line f)
>        return 1
>     end type
> </eucode>
{{{

> 
> As Salix pointed out "sequence of sequence of integer" simply does not hold
> a candle to the code readability of a "name_table" type definition.
> Obviously I accept the above is alot more typing .. and alot nicer.
> 
> There are also some technical points I missed.
> }}}
<eucode>
> set_table k
>     k[5]=z
> </eucode>
{{{

> If z is already type set, then you would not need to call set() as a result
> of this assignment. You can compare an explict type definition instantly, 
> while
> you would still have to walk down the type-chain as each "[" is processed, it
> is obviously simpler than judging that "7 sequence of plus integer plus 3
> subscripts"
> matches a replacement element of "4 sequence of plus integer".
> 
> Because you are only changing k[5], then in the type set_table() definition,
> you do not need to type check the parameter st, but can invoke the udt after
> the leading TYPE_CHECK_SOF opcode (or do nothing if that would just be a
> return
> 1 as shown).
> 
> In this way, a smart compiler and sensibly written code will often avoid
> launching
> a daisy chain of types, and hopefully optimise away any of the "return 1"
> bodies
> without much trouble. If it can do that last trick, I see no reason why it
> would
> be any slower than a hidden/inline implementation, and it will be easier to
> write sensible compiler-friendly code.
> 

Is't it easier for the compiler to see the whole of the daisy chain, and
optimise as you said, if the type is presented as a whole?
Otherwise, the compiler has to reassemble a few nested type declarations into
the whole thing. More work both for coder and compiler, with nil benefits and
perhaps a slight loss of performance.

> > > 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.
> > 
> > Optimize away the expression first, then perform the tests. Why raising an
> > error?
> Because it is redundant and potentially misleading. Why allow it?
> 

Because of the overhead of testing for it, because there is no example of such
limitations in Eu, because it doesn't hurt since the last "object" will be simply
ignored.
I remember your writing "exceptions simply beget exceptions". That would be the
short answer.

CChris

> Regards,
> Pete