[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 12 10:59:35 1994 
Subject:Re: Functional Programming Languages with Lazy Evaluation 
From:Steve Knight 
Volume-ID:940513.02 

Robert John Gaizauskas (R.Gaizauskas@uk.ac.sheffield.dcs) wrote:
> Has anyone out there considered implementing a functional language
> with lazy evaluation, such as Miranda or Haskell, in Poplog ?

Yes, I've been through this loop a couple of times.  An implementation
of a "full" language such as the two mentioned is a fair amount of
work.  I suggest structuring the work as follows:-

Tokeniser: assume the Pop11 tokeniser.  This isn't correct, of course,
    but I think a student would be wasting their time doing a custom
    tokeniser.  (I think a LEX equivalent would be a good 3rd year project in
    itself.)

Parser: use the new define_parser syntax.  Again, unlikely to be 
    perfect and the same comments apply.  The important thing is to
    get the student working from the parse-tree from day 1.

Type-checker: leave as optional.  If there is enough time this can
    be tackled as second part.  Of course, this means that a few elegant
    optimisations will be impossible (e.g. the elimination of store
    allocation for constructions in singleton datatype declarations such
    as    datatype Foo = Foo of int; )  

    This implies that you should choose a language such as KRC or Miranda,
    which either have dynamic type-checking or still make sense with
    dynamic type-checking.  Haskell and type-checking are too closely 
    linked.

Code generation: this is the core of the work.  For a fully lazy language
    there are a number of well-understood strategies.  In the past I have
    done this by implementing a special type of "delay" object and inserting
    "forces" at appropriate points.  This is simple -- but the efficiency
    depends on the quality of strictness analysis.  Graph reduction is 
    great fun, too.  It is radically different in concept, but if you
    generate supercombinators then you can implement them as procedures
    (and one nice challenge is to avoiding generating superfluous copies of
    common supercombinators.)

Analysis for optimisation: again, an optional phase, probably best considered
    as lower priority than writing a type-checker.  But great fun.

So, with this structure, I think it would be a reasonable (though moderately
difficult) project for a good student.

Steve