Re: Homogeneous sequence
Pete Lomax wrote:
>
> Jason Gade wrote:
> >
> > Reading this thread with interest and yet with reservations also.
> >
> > According to the proposal would I be able to do something like this:
> > }}}
<eucode>
> > sequence of integer x
> > sequence y
> > object z
> >
> > -- some code assigning values to x, y, and z
> >
> > x = y -- typecheck y to make sure it complies with the definition
> > x = z -- ditto
> > </eucode>
{{{
> >
> > Or would it fail right away because the type definitions do not match?
>
> I am sure you fears are unfounded.
>
> First, the typecheck both times is on x to ensure the new value fits.
> (error: type check failure, x is -1)
So if y is a sequence of integers except for y[$] which is 1.1, at what point is
x checked for validity? Is it an O(N) operation or an O(1) operation?
Doesn't Euphoria usually just copy the pointer internally?
> Type checking is always done after the effect, for such messages.
> It is no different to y=z, failing (only) when z is not a sequence.
>
> The objective is to perform less type checks, not more. y=x would perform no
> typecheck whatsoever, because the compiler has enough type info to know it
> will
> succeed, ditto z=y and z=x. More detailed type info === even less checks.
I agree with performing fewer typechecks. And with needing to perform fewer.
>
> Actually this point is debateable: currently more detailed checks are so
> expensive
> no-one does them; if we slash the cost then argubly more people will use them,
> which is also an objective.
>
> Type-wise, you should note that the compiler can seem thick as pigshit:
> }}}
<eucode>
> integer i
> i=3.5
> i="fred"
> </eucode>
{{{
> compiles/binds/translates without hitch. It only goes wrong at run-time; it
> is only the backend that knows much about type errors. Obviously the front-end
> is actually pretty smart about emitting the right code for the right types,
> just not about predicting type errors. Reasonable, I guess.
>
> HTH,
> Pete
IIRC, before Euphoria's front-end was re-written, Rob was pretty proud of the
speed of the interpreter's front end. Plus the fact that it would continue
converting code to IL and executing code at the same time.
Checking for certain obvious type errors in the front end makes a lot sense, but
I've already seen some people complain about the slowness of the front end. (I'm
not one, BTW).
Hmm. This is a tangent, but it would be interesting for the front end to use the
tasking feature maybe to do some of this... Except the back end would have to be
aware of it also.
The Euphoria to C translator should definitely be doing those kinds of checks
though.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
|
Not Categorized, Please Help
|
|
