On Sun, 18 Sep 2005, Jon Harrop wrote:

> > You cannot directly compile LISP code to ML code in the sense that
> > (...)
> > for a ton of reasons.

> In this case, what else is needed beyond replacing operators with those 
> suitable for a generalised numeric type and constructing numeric literals?

I have to correct my statement:

You cannot compile Common Lisp code to ML code that expresses the same 
idea short of piping it through an intelligent human who is proficient 
with both languages, and can use intelligent judgment to make decisions 
about what "the same idea" is supposed to mean.

The question whether there is an interesting subset of Common LISP which 
can automatically be mapped directly to ML in such a way that there is a 
direct correspondence between the fundamental data types (i.e. lists are 
represented as lists) is a different one.

May I ask you to have a try here:

(defun flatten (tree)
  (cond
   ((consp tree)
    (append (flatten (car tree)) (flatten (cdr tree))))
   ((null tree) nil)
   (t
    (list tree))))

(flatten
 '("foo" (bar (1337 "baz") ("some" "more") ("pieces" "of" ("data")) "here")))

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)