markv@uoregon.UUCP (Mark VandeWettering) (12/03/87)
In article <584@zippy.eecs.umich.edu> dwt@zippy.eecs.umich.edu (David West) writes: >Applicativity has its advantages, but it needs >1) a more humanly-comprehensible syntax than LISP; Miranda (TM) is excellent > in this respect, but the (TM) will probably doom it, as apparently was the > case with COMIT (TM). I have just recently become interested in functional/applicative prramming. Having read several essays on Miranda, I am amazed at the high level that programs can be described in Miranda. While suffering from some problems (as noted by Dave West), Miranda seems excellent for simple and not-so-simple programming jobs. >2) Some syntactic means for preventing argumentsfrom getting unreadably > numerous just to pass something down to where it's finally used. I have seen an extension to prolog for object-oriented programming that works in much this way. Normally, object state is represented by a structure which is passed and has fields (corresponding to instance-vars) bound to new values as the object changes state. This allows you to backtrack through object changes, which would be hard to do if we used real assignment. But passing these objects around is tedious, so "syntactic sugar" is developped to carry the object state around. For more info, see University of Oregon Tech Report -TR-87-09, "Object Oriented Programming with First Order Logic", by John S. Conery. >3) a public domain portable optimizing implementation (though all three of > these attributes together is perhaps too much to hope for.) The thing > that made Pascal fly was the availability of the Zurich P-compiler > initially, then Turbo. What the world needs now is GNU Miranda or (ok, > I'll be more reasonable) GNU ML. (Richard is probably too busy, though...) > Turbo ML? Hmmm, not a bad idea. I have just acquired "Implementation of Functional Programming Languages by Simon L. Peyton Jones, and am much impressed by the depth/level of the text. Seeing as I have to do a final thesis/project sometime :-) I might be tempted to try a hand at an ML interpreter/compiler. I would like to hear from anyone who is trying/has tried similar projects. markv@uoregon.edu \ Mark Terrence VandeWettering University of Oregon \ ..!tektronix!uoregon!markv Computer Science Dept. \
csnjr@its63b.ed.ac.uk (Nick Rothwell) (12/08/87)
In article <1202@uoregon.UUCP> markv@drizzle.UUCP (Mark VandeWettering) writes: >In article <584@zippy.eecs.umich.edu> dwt@zippy.eecs.umich.edu (David West) writes: >>Applicativity has its advantages, but it needs >>1) ... >>2) Some syntactic means for preventing argumentsfrom getting unreadably >> numerous just to pass something down to where it's finally used. > > Hmmm, not a bad idea. I have just acquired "Implementation of > Functional Programming Languages by Simon L. Peyton Jones, and > am much impressed by the depth/level of the text. Seeing as I > have to do a final thesis/project sometime :-) I might be > tempted to try a hand at an ML interpreter/compiler. I would > like to hear from anyone who is trying/has tried similar > projects. ML gives you objects with modifiable state, so that you don't need to pass a state structure around with you. The disadvantage, of course, is that you smash the applicative behaviour of the language - whether it's worth it depends what you're trying to do. Another way around this is to use type abstraction. That way, your state structure is an abstract object with a few access functions to get at the bits you need. I've always used the former approach, so I don't know how far the latter approach gets you. It's quite possible to take non- applicative features like assignment and abstract over them to build structured objects with varying state, a la Smalltalk perhaps. This isn't "dirty" functional programming - it's just using a functional language as if it were a language of a different kind. I recently dedicated a lecture to the structured use of side-effects in ML. By the way, I have various little typecheckers and interpreters for tiny functional languages lying around on-line somewhere, if you're interested. All written in ML, of course. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "Nothing's forgotten. Nothing is ever forgotten." - Herne
ok@quintus.UUCP (Richard A. O'Keefe) (12/15/87)
The languages described in Peyton-Jones's book are Miranda and
>>>Lazy<<< ML.
DEC-10 ML and VAX ML are strict languages. They do have
(monotyped) assignable objects. Peyton-Jones's book has nothing
to say about their implementation. Lazy ML is a lazy language
(normal-order evaluation), and to the best of my knowledge it
does not have assignable objects.
If people are interested in trying Lazy ML out, rather than in the
mechanics of writing compilers, they might prefer to get a copy of
the Lazy ML system. (In fact, if you *are* interested in the
mechanics of writing compilers, you might get it anyway; you will
learn a lot.) I have seen a copy, and was much impressed by it.
You should contact
Lennart Augustsson augustss@chalmers.csnet
...!mcvax!enea!chalmers!augustss
or
Thomas Johnsson johnsson@chalmers.csnet
...!mcvax!enea!chalmers!johnsson
paper-mail:
Dept of Computer Science,
Chalmers University of Tech.
412 96 Gothenburg
Sweden