Day 161: Prototype PIL evaluator in Perl 5.

autrijus on 2005-07-14T17:47:45

Today I did a lot of reading and much less coding. Meijer's Static Typing Where Possible, Dynamic Typing When Needed is very close to lwall's position on Perl 6, and I think a non-intrusive inferencer will be a Good Thing for Perl. A certain summer coder, Gary Jackson, is working on such an inferencer for Perl 5, and I eagerly anticipate his work.

To me, the gist of Meijer's positions is maximizing inference power with optional type annotation, yet do not shy away from runtime checks where static checking becomes infeasible:

  1. We should not ditch runtime typechecks as static typing people usually do; otherwise Array of Num becomes monomorphic, and you can't even store an Int into it without verbose casting or wild-card type annotations.
  2. We should not ditch type inference as dynamic typing people usually do; inferencing makes program much more concise and optimizers much more efficient -- one can even derive constructors automagically based on static information.

Also I started learning Erlang. For single-process applications, its expressive power is less than Haskell, and I miss static types (but not much), but its handling of messaging and recovery is very elegant. STM captures some of the elegance, but single-assignment makes things so much easier -- after all, variables are much nicer when they cannot change. ;-)

While I was in study mode, some lambdacamels are madly hacking. putter popped up with lots of PIL questions to a confused stevan; we didn't understand what he was getting at, until putter revealed crude_repl.pl, a working Perl 5 interpreter that parses and runs Haskell PIL structures. It is exceedingly kludgy, but we are all suitably impressed:

 oh wow, a Hs parser
 I think that deserves a respectful silence. or a frightened one.
 putter: I just thought you were curious, but you are serious :)

Aankhen and iblech did a very simple eval.p6 that evaluates Perl 6 code with eval and $result.perl; I wonder if someone will export the pluggable evaluator (envEval) and evolve this into a debugger shell...

fglock, continuing his work on Span.pm, produced Span::Code, a two-way iterator and recurrence set interface defined with closures. It is quite expressive; see the "all non-zero integers" demo in the synopsis for an example.

On the metamodel front, stevan hacked in submethod support, which verifies that the invocant is indeed monomorphic to the containing class.

scook0 prettified the Haddock a bit; masak wants .<key> = 'value' and wrote tests for it; rafl refactored our debian packaging metadata; iblech... well, did lots of things as usual. :-)

Oh, and it looks like cwest may start adopting an anarchistic model for JSAN development, beginning with the #jsan channel in irc.freenode.net, a public svn repository, in addition to the jsan-devel mailing list. Best wishes to cwest and the imminent legion of rhinocamels!


Type Inference vs. Abstract Interpretation

Greg Buchholz on 2005-07-14T20:33:20

Lately I've been thinking that maybe the best way to implement the 'slider' between static and dynamic typing is to do an abstract interpretation of your program operating on types instead of values. Here's two of my recent ramblings on the subject. BTW, is Perl6 going to have any partial evaluation features? Will there be any compiler flag so that something like...
fibonacci(35)
(which has no run-time dependencies) get optimized into a number at compile time? Or will we have to do it by hand with macros?

Partial evaluation

autrijus on 2005-07-15T01:53:30

Yes. It's specced in A06 and S06 as sub fib ($n) is cached { ... }. Normally this would be a runtime cache, but coupled with a toplevel use optimize <close>, symbols can't be rebound in fib, so the optimizer can do a static analyzation and choose to evaluate this in the compile time.

First-class types and pattern bindings (the function signature kind, not the rules kind) are one of the more exciting features in Perl 6, and I've been pushing for ML-style unification based type variables, which can be bound at compile time via inferencing and part of eg. type classes known as roles, or at runtime as an alias to a term's actual type. See larry's #1 and larry's #2 about this.