Re: [Chicken-hackers] specialization

[Alaric Snell-Pym]

On 08/08/2011 06:51 AM, Felix wrote:

[many quite subtle and cunning bits of type analysis]

Awesome! Great work, Felix! Work like this chips away at the argument
that primitive, feature-poor, languages are required to produce
performant code...

> The results of the type-analysis can be somewhat improved, under the
> assumption that variables are "strictly" typed, which means that they
> do not change their type by assignment. The compiler option
> "-strict-types" will enable this mode but violating these assumptions
> will result in undefined behaviour. This also applies when core
> library procedures are redefined. Optimization levels 2 and higher
> assume standard and extended bindings are not globally modified, so
> this is not new, but specialization will quickly result in incorrect
> rewriting of the source program in such cases.

Is there a way of running untrusted (compiled; obviously, EVAL is a
different world entirely) code in a sandbox so that it can't mutate
globals, out of interest? I mean, EVAL-ing untrusted code is all well
and good, but it'd be nice to compile it into a .so and then LOAD it on
the fly, too.

> Global definitions can have type declarations, like this:
>
>    (: foo (string ->  number))
>    (define (foo str) ...)
>
> Implicit type-declarations are done for unexported toplevel bindings
> or when using "-block" or "-local" (the latter being implied by
> optimization levels 3 and higher). You can view these with "-debug I".
> Usually the declaration should precede the definition. With
> "-strict-types" the compiler will assume the formal parameters of the
> associated definition will have the types indicated.
>
> Type-information can be written to a file ("-emit-type-file") and
> installed. The compiler will automatically load files with the
> ".types" extension from the repository for extensions imported with
> "require-extension" or "use". This feature has not been tested much,
> but opens up the possibility for extending the available type
> information for extensions.

That's good. Are the .types files just Scheme source files that happen
to only contain a series of global type declarations, or something like
that?

> There is now a "the" (similar to the "the" found in Common Lisp),
> which can be used to declare an expression's type inline. There
> also is an "assume" that does local variable type declarations:
>
>    (assume ((x pair) (y number)) ...)
>
>    ~>
>
>    (let ((x (the pair x)) (y (the number y))) ...)
>
> Caveats:
>
> Violating type-declarations will result in undefined behaviour.

Shouldn't THE expand to include an assertion of the type (which can be
elided if the optimiser already knows that the type holds), as well as
introducing knowledge that the return value of THE is of the declared
type? So violating the declaration results in defined failure behaviour?

> For local use on the other hand, there is a cleaner form of specifying
> rewrite rules, say:
>
>    (define-specialization (foo (x fixnum) (y float))
>      (frob-fix-and-flo x y))

That's very neat! What do you think about making object-oriented
extensions interface with this when declaring methods? Is it practical?

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/