Re: [Chicken-hackers] specialization

[Felix]

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

Well, it depends. It will not make everything magically faster,
I'm afraid.

> 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.

As long as one can use the foreign function interface or internal
procedure it will always be possible to subvert the type system.
Compiling code inside a module can help, but what you describe
will need more customization. But it's an interesting idea, perhaps
I can figure something out that goes into that direction.

>> 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?

Just a list of s-expressions mapping identifiers to types, like the stuff
found in types.db.

> 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?

The intention is to detect violations statically. Given "-verbose", the
compiler will issue a warning when the type given in the "the" expression
is not a subtype of the type inferred during flow analysis (if there
is some distinct type that can be inferred). Checking the type on the
other hand is a different operation. I thought about adding a "check-type"
form (similar to the one found in CL) that takes advantage of the known
type information, but haven't decided you what to do. There is some
(currently disabled) code to generate type-checks from type-specifiers,
but since one would like to have these checks also in interpreted code,
integrating this in a usable manner is a bit more work and needs some
recfactoring.

> 
>> 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?

It would be quite nice to have something like this, where OOP forms
interact with compiler-obtained type information, but again, this is
something to think more about. If the type-checks for method selection
can be pushed into the call-site, scrutinizer information would be
very helpful indeed. The "fast-generic" extension does something in
that direction, but is difficult to use across compilation units.


cheers,
felix