I am planning an AI course, and as most books are in LISP, I am wondering;
1) why more AI folks have not converted to ML. ML seems to have higher level
abstraction benefits over LISP, and the only thing I can see that it lacks
(for this application) is eval; a big thing, but which I don't use in my intro
classes.
Is there any reason for this other than familiarity and stylistic
preferences?
2) It seems like one could rather mechanically translate most LISP code to ML,
I wonder if anyone has built any tools for this?
Thanks for any insights or experience in this area.
------------------------------------------
Gregory Guthrie MUM Computer Science
·······@mum.edu (515)472-1125
FAX -1103
------------------------------------------
Gregory Guthrie wrote:
>
> I am planning an AI course, and as most books are in LISP, I am
> wondering;
>
> 1) why more AI folks have not converted to ML. ML seems to have
> higher level abstraction benefits over LISP, and the only thing
> I can see that it lacks (for this application) is eval; a big
> thing, but which I don't use in my intro classes.
MLWorks has "eval" as part of an "experimental implementation of
dynamic types". Haven't had any call to use it myself (even
when I was programming in Scheme), but that an SML implementation
supports it at all is pretty interesting.
-thant
--
thant at acm dot org
In article <············@goldenapple.srv.cs.cmu.edu>,
Thant Tessman <·······@signature.below> wrote:
>Gregory Guthrie wrote:
>> I am planning an AI course, and as most books are in LISP, I am
>> wondering;
>> 1) why more AI folks have not converted to ML. ML seems to have
>> higher level abstraction benefits over LISP, and the only thing
>> I can see that it lacks (for this application) is eval; a big
>> thing, but which I don't use in my intro classes.
>MLWorks has "eval" as part of an "experimental implementation of
>dynamic types". Haven't had any call to use it myself (even
>when I was programming in Scheme), but that an SML implementation
>supports it at all is pretty interesting.
For some purposes, Lisp macros can give some amazing flexibility.
--Travis
> >Gregory Guthrie wrote:
>
> >> I am planning an AI course, and as most books are in LISP, I am
> >> wondering;
>
> >> 1) why more AI folks have not converted to ML. ML seems to have
> >> higher level abstraction benefits over LISP, and the only thing
> >> I can see that it lacks (for this application) is eval; a big
> >> thing, but which I don't use in my intro classes.
Hmmm... I ought to learn more about ML, I suppose --
I use Lisp (well, Scheme to be precise) because I
find it remarkably clear and easy to read and
understand. It's really hard for me to imagine
anything plainer than fully parenthesized prefix
notation, (even though I know a lot of people are
just horrified at the number of parentheses in
Lisp/scheme code, they clarify more than they
obscure, to me).
Just out of curiosity, how would a simple one-argument
function composition function be written in ML? In
scheme it goes like this:
(define (compose F G)
(lambda (x) (F (G X))))
Now, if your Lisp->ML translator
read this function, what would it output?
Bear
[Follow-ups restricted to comp.lang.scheme.]
Ray Dillinger <····@sonic.net> writes:
> Just out of curiosity, how would a simple one-argument
> function composition function be written in ML? In
> scheme it goes like this:
>
>
> (define (compose F G)
> (lambda (x) (F (G X))))
You wish. Consider:
(define f (lambda (a b) (cons a b)))
(define g (lambda (x) (values x x)))
((compose f g) 3)
'shriram
Ray Dillinger <····@sonic.net> writes:
>Just out of curiosity, how would a simple one-argument
>function composition function be written in ML? In
>scheme it goes like this:
>(define (compose F G)
> (lambda (x) (F (G X))))
let compose f g = fun x -> f (g x);;
or
let compose f g x = f (g x);;
in o'caml. SML would be very similar.
>Now, if your Lisp->ML translator
>read this function, what would it output?
Probably the former.
Andrew.
Ray Dillinger <····@sonic.net> writes:
> (define (compose F G)
> (lambda (x) (F (G X))))
>
> Now, if your Lisp->ML translator
> read this function, what would it output?
fun compose (f, g) x = f (g x);
And its type would be
val compose = fn : ('a -> 'b) * ('c -> 'a) -> 'c -> 'b
(the "val" line is produced by SML/NJ 109.29 when the "fun" line is
typed at it.)
SML handles currying implicitly; "fun compose (f, g) x = f (g x)" is
a function that takes a single argument (a pair containing f and g),
and returns a function that takes a single argument (x) and returns
the result of applying f to (g applied to x). (All the types are
checked at compile-time to make sure that f, g, and x are functions
whose types match appropriately).
A truly sophisticated translater could note that function
composition is a built-in function ("o") in SML, and either emit
fun compose (f, g) = f o g;
or simply translate each use of "compose" to use the infix "o"
operator.
(See why it's fun? Now, if they'd just allow overloading as well as
polymorphism, so you could say things like "fun square x = x * x"... :-)
)Rob
Rob Earhart wrote:
>
> Ray Dillinger <····@sonic.net> writes:
> > (define (compose F G)
> > (lambda (x) (F (G X))))
> >
> > Now, if your Lisp->ML translator
> > read this function, what would it output?
>
> fun compose (f, g) x = f (g x);
>
> And its type would be
>
> val compose = fn : ('a -> 'b) * ('c -> 'a) -> 'c -> 'b
>
> (the "val" line is produced by SML/NJ 109.29 when the "fun" line is
> typed at it.)
>
> SML handles currying implicitly; "fun compose (f, g) x = f (g x)" is
> a function that takes a single argument (a pair containing f and g),
> and returns a function that takes a single argument (x) and returns
> the result of applying f to (g applied to x). (All the types are
> checked at compile-time to make sure that f, g, and x are functions
> whose types match appropriately).
I'm duly impressed. I thought that the ML system would stumble
hard on the type question, and it looks like it's at least
understood what "the right thing" in this case is. (someone has
explained to me that the tickmarks in front of the type designations
mean "some type" instead of any *particular* type).
If ML can handle a statement as type-ambiguous as this, then the
*worst* fears of most LISPers about static typing are groundless.
There may be a few places where it falls down, but if it handles
that fragment correctly, then I suspect that those places lie a
little bit further outside the range of "typical" programs.
Bear
> A truly sophisticated translater could note that function
> composition is a built-in function ("o") in SML, and either emit
>
> fun compose (f, g) = f o g;
>
> or simply translate each use of "compose" to use the infix "o"
> operator.
>
> (See why it's fun? Now, if they'd just allow overloading as well as
> polymorphism, so you could say things like "fun square x = x * x"... :-)
>
> )Rob
Ray Dillinger (····@sonic.net) wrote:
: Just out of curiosity, how would a simple one-argument
: function composition function be written in ML? In
: scheme it goes like this:
: (define (compose F G)
: (lambda (x) (F (G X))))
: Now, if your Lisp->ML translator
: read this function, what would it output?
Probably something like
fun compose F G =
fn x => F (G x)
In fact, you can define this infix (as it's done in the SML basis library)
infix 3 o
fun f o g =
fn x => f (g x)
which lets you write A o B o C o D instead of
(compose A (compose B (compose C D)))
Of course one can argue that infix operators are confusing because they
obscure precedence ...
xtof
--
Christoph Kern <·····@cs.ubc.ca>
In article <············@goldenapple.srv.cs.cmu.edu>,
Gregory Guthrie <·······@mum.edu> wrote:
> I am planning an AI course, and as most books are in LISP, I am wondering;
>
> 1) why more AI folks have not converted to ML. ML seems to have higher level
> abstraction benefits over LISP, and the only thing I can see that it lacks
> (for this application) is eval; a big thing, but which I don't use in my intro
> classes.
> Is there any reason for this other than familiarity and stylistic
> preferences?
>
> 2) It seems like one could rather mechanically translate most LISP code to ML,
> I wonder if anyone has built any tools for this?
>
> Thanks for any insights or experience in this area.
As an AI folk with a reasonable amount of ML experience, I think
I can give a few other important reasons why it isn't the
programming language of choice for most AI folks:
1) Dusty decks. There's a large amount of existing
AI code around written in LISP; conversion is a
non-trivial amount of work. There's starting to
be more implementations of AI-ish things in ML,
but it really hasn't caught up yet.
IMHO it is probably straightforward to mechanically
translate Common Lisp to ML, but probably very
difficult to make this a useful process. Since the
CL compilers are generally very good, there will be
no obvious performance win. It is probably also
difficult to produce translations which preserve
human readability.
2) Implementation maturity. There's really a very
small number of full SML native code compilers out
there, and as near as I can tell there's still a lot
of experimentation going on with all of them.
SML/NJ is the de-facto standard, but the over-large
executables, slow inner loops, and lack of commonly
requested facilities like a reliable debugger,
convenient I/O functions, and the ability to build
small standalone executables make it awkward to use
for many critical tasks in my experience.
3) Standardization. Just, when I was getting used to
Standard ML, the standard changed in significant
ways. And CAML and friends, while undoubtedly very
nice, are different from *both* SML and ML2K. So we
have 3 different dialects of ML floating around,
with important differences.
Common Lisp, in the grand tradition, papered over
this by allowing conditional compilation; IMHO this
is clearly the wrong thing, but it beats ML's
approach of no hope at all. The biggest disaster
here for me has been ML2K changing the behavior of
some of the basis functions I used all the time
without changing their name.
I'd really like to write AI code in ML. Unfortunately, right
now, our lab is stuck with C for new code and Common Lisp for
existing code; I'm hoping the former will change in the near
future, but I'm doubtful. If so, I suspect it will be to Java
rather than ML, for a variety of reasons including (2) and (3)
above.
Bart Massey
····@cirl.uoregon.edu
"Barton C. Massey" <····@cirl.uoregon.edu> writes:
> 3) Standardization. Just, when I was getting used to
> Standard ML, the standard changed in significant
> ways. And CAML and friends, while undoubtedly very
> nice, are different from *both* SML and ML2K. So we
> have 3 different dialects of ML floating around,
> with important differences.
I think you mean SML'97, not ML2K. SML'97 was a set of minor revisions to
the Definition of Standard ML, and the incorporation of a standard Basis
Library. ML 2000 is a research project which (AFAIK) is still in progress.
The Lisp world has several versions floating around as well. The differences
between CLtL 1, CLtL 2 and ANSI/ISO Common Lisp correspond loosely to
the SML'90/'97 differences. And there are other variants of Lisp around,
which are analogous to the non-standard dialects of ML.
Dave.
--
Harlequin Ltd., Technology Transfer Centre, King's Buildings,
Mayfield Road, Edinburgh, EH9 3JL, UK.
Tel: +44 131 472 4782
Gregory Guthrie wrote:
>
> I am planning an AI course, and as most books are in LISP, I am wondering;
>
> 1) why more AI folks have not converted to ML. ML seems to have higher level
> abstraction benefits over LISP, and the only thing I can see that it lacks
> (for this application) is eval; a big thing, but which I don't use in my intro
> classes.
> Is there any reason for this other than familiarity and stylistic
> preferences?
Lisp has many higher level abstraction benefits over ML.
Sadly, many elementary AI textbooks are not going to teach
enough Lisp for one to see them. That's because Lisp was the
first AI language, so historically it provided low-level,
less abstract tools for AI. Many elementary AI textbooks use
the low-level tools for the short-sighted reason that it lets
the student "get to the AI" faster.
A Lisp construct usually exceeds an ML construct by giving you
more freedom. You can do mapping, and make map of a function
return a new function. Lisp's object-oriented system, CLOS, gives
you extremely flexible polymorphic functions. You can do incredible
things with macros--see Graham's book (below).
I am **NOT** saying ML is bad, or weak, or anything like that.
I view it as a proper subset of Lisp with a very clean syntax.
It has many of the benefits of Lisp, with less opportunity to
shoot oneself in the foot. Also, the fact that the type of every
object must be known at compile time helps the programmer.
------
I do not know the AI textbooks that would directly teach enough
Lisp to back up my claims. This is because I don't know AI.
Can anyone else help?
Winston and Horn, _Lisp_, Addison-Wesley, 3rd ed. is an excellent
Lisp textbook with (IMHO) an AI flavor. A companion is
Winston, _Artificial Intelligence_, an intro AI textbook.
A "first course" that shows Lisp [really Scheme] in all its depth is
Abelson and Sussman, _Structure and Interpretation of Computer
Programs_. A course from this book, with emphasis on AI topics,
would be challenging and fantastic.
A book that really shows what Lisp can do with abstraction is
Graham, _On Lisp_, Prentice-Hall. For instance, it shows how to
write a Prolog interpreter in Lisp in about 200 lines.