From: Tom Kramer
Subject: Translating Franz Lisp to Common
Date:
Message-ID: <1196@cayman.cme.nbs.gov>
I have translated a few hundred lines of Franz Lisp code into Common Lisp.
I had written the Franz code myself. For stylistic reasons (I always
used def rather than defun in Franz), not one function could be used as
as is. Even without the style problem, only the simplest functions
(one or two lines of car's, cdr's, mapcar's, etc.) could be used without
alteration.
Around the end of 1988 I inquired from Franz, Inc. whether they had any
programming aids to give to users for translating Franz to Common. They
did not.
I have not heard of a translator program. To write a translator that would
handle a moderately complex (50 twenty-line functions) software system in
Franz with only a few errors and inefficiencies, would take several months
solid work, I think. On the other hand, a translator limited to, say, 50
of the most used Franz functions that differ only slightly from Common
functions of the same name or have differently named but similarly behaved
counterparts could be banged out in a few days.
I wrote a brief (5 pages) comparison of Franz and Allegro Common for my own
use. It covers about 200 Franz and Common functions, with one line per
function. I will be glad to send it to E-mail requestors.
From: John Gilmore
Subject: Porting Franz Lisp to run under Gnu C
Date:
Message-ID: <7487@hoptoad.uucp>
I have been working on making the whole BSD Unix system compile under
gcc (the GNU C compiler). UCB intends to use gcc as "cc" in future BSD
releases, though the old pcc compiler will still be around somewhere.
One big stumbling block is Franz Lisp, which is rife with machine- and
compiler-dependencies. Rather than replace these fragile dependencies
with different fragile dependencies, I have been removing them, making
the code more portable.
After a few days' work, I have the Lisp interpreter compiling with gcc
and pcc (and presumably any other C compiler). There are a few loose
ends to smooth out but it's basically there. However, the Lisp
compiler is another matter; it seems to have lots more buried
assumptions about how various C language "global variables" (the stack
pointers) have magically been put into global machine registers.
It looks like this is turning into a bigger effort than I and Berkeley
can support. Two questions: Does anyone care if Franz Lisp moves into
/usr/old and is desupported in BSD releases? And, is there anyone who
wants to take on the Lisp compiler conversion themselves?
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu ···@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.
From: Jeff Dalton
Subject: Re: Porting Franz Lisp to run under Gnu C
Date:
Message-ID: <517@skye.ed.ac.uk>
In article <····@hoptoad.uucp> ···@hoptoad.uucp (John Gilmore) writes:
>the Lisp compiler is another matter; it seems to have lots more buried
>assumptions about how various C language "global variables" (the stack
>pointers) have magically been put into global machine registers.
Is this true for every target machine? I know that the VAX version
assumes that, but I'm pretty sure the 68k one doesn't. Indeed, I think
it has a switch that lets you say whether C register hacks have been
applied or not.
How many different machine architectures have to be supported these
days? Is it supposed to work on the Tahoe?
>It looks like this is turning into a bigger effort than I and Berkeley
>can support. Two questions: Does anyone care if Franz Lisp moves into
>/usr/old and is desupported in BSD releases? And, is there anyone who
>wants to take on the Lisp compiler conversion themselves?
I guess I would like to see Franz supported, but I don't think it's
so important now as it was in the past.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
From: Charles A. Cox
Subject: Re: Porting Franz Lisp to run under Gnu C
Date:
Message-ID: <29535@ucbvax.BERKELEY.EDU>
In article <···@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In article <····@hoptoad.uucp> ···@hoptoad.uucp (John Gilmore) writes:
>>It looks like this is turning into a bigger effort than I and Berkeley
>>can support. Two questions: Does anyone care if Franz Lisp moves into
>>/usr/old and is desupported in BSD releases? And, is there anyone who
>>wants to take on the Lisp compiler conversion themselves?
>
>I guess I would like to see Franz supported, but I don't think it's
>so important now as it was in the past.
Just to make sure there's no confusion, this discussion is about the
old Opus 38 Franz Lisp available with UNIX BSD distributions. Newer
versions of Franz Lisp (currently Opus 43) are supported and available
from Franz Inc. (ask ····@franz.com for more information).
Charley Cox
···@Berkeley.EDU
From: Drew Adams
Subject: Re: Translating Franz Lisp to Common
Date:
Message-ID: <4660@crcge1.UUCP>
In article <····@cayman.cme.nbs.gov> ······@cme.nbs.gov (Tom Kramer) writes:
>
>Around the end of 1988 I inquired from Franz, Inc. whether they had any
>programming aids to give to users for translating Franz to Common. They
>did not.
>I have not heard of a translator program. To write a translator that would
>handle a moderately complex (50 twenty-line functions) software system in
>Franz with only a few errors and inefficiencies, would take several months
>solid work, I think.
---------------------------------------
In 1984 I wrote a translator program, FTOC (Franz To Common), which has been
used a bit here and elsewhere, since. It (source) is available to anyone for
"research" (i.e. non-commercial) purposes. It was written for an
old version of Franz (I forget which). The basic program works fine, but
its correctness depends on the correctness of the set of rewrite rules used
to define the language-language translation. These could be improved, and
some are even known to be incorrect. No guarantees are made, of course.
The program works by simple macro-expansion (but not evaluation), i.e.
"reduction". It may also be used for any other (Lisp-like) language-language
translation. (You'll need to define the rewrite rules. Yes, THAT is a lot
of work -- it means translating every language expression, if you want a
"complete" translator.)
No translation program is satisfactory, obviously (there are lots of
untranslatable things). FTOC tries to be prudent, rather than clever;
whenever possible it tries to maintain the semantics of the original code,
rather than "optimizing". Different, more liberal, rewrite rules could of
course be used.
FTOC is written in Common Lisp, and has run on VAX with VAX-VMS Common Lisp,
and on Sun with KCL and Lucid. No claims on portability are made, but I
don't recall it using any implementation-dependent features. FTOC does use
the Common Lisp reader, so some porting problems may arise regarding character
case, filenames etc.
FTOC may be used interactively, as well, as a sort of (slow) Franz front end
to Common. This is sometimes useful when Franz programmers start to learn
Common -- Franz expressions may be translated on the fly and, optionally,
executed in Common.
In addition to the source, a User's Guide is available. I will try to
respond to requests for the program promptly, but I'm a bit overloaded
with work, so ...
A few remarks:
FTOC should be regarded as an AID to translation, rather than an
automatic translator.
The biggest difference between Franz and Common is that Common uses
static scoping of variables (in general). Franz code which depends
on dynamic scoping cannot, generally, be translated (automatically).
FTOC makes no attempt to wrestle with this problem; it is ignored.
Type predicates, after translation, refer to COMMON Lisp types.
For example, the Franz predication (BIGP ...) is translated to
the Common predication (TYPEP BIGNUM ...)
Franz code which manipulates or produces CODE which is SPECIFICALLY
Franz will normally NOT work, of course, after translation to COMMON.
However, FTOC users may optionally choose to have macro definitions
expanded during translation. This may help in some cases.
Whenever an expression translation is not straightforward (the
result isn't immediately recognizable as a translation of the input
by the programmer), the result code is enveloped and labelled for
recognition, with an FLET. That is, temporary named functions are
created, whose names correspond to the source code names (prefixed
by "FRANZ"). Further info on the correspondance is available using
the Common Lisp function DOCUMENTATION.
Finally to show one of the worst kinds of thing that can happen, because
of the desire not to modify the original semantics, here is the Common Lisp
code resulting from the Franz expression (+ 2 (+ 3 (+ 4 1))):
[Things aren't normally this bad!]
(flet ((franz.+ (&optional (n1 0) &rest n2etc)
"equivalent to Franz Lisp '+'."
(check-type n1 fixnum)
(mapc #'(lambda (n) (check-type n fixnum))
n2etc)
(if (endp n2etc)
n1
(+ n1 (reduce #'+ n2etc)))))
(franz.+
2
(flet [.... AS ABOVE ...]
(franz.+
3
(flet [.... AS ABOVE ...]
(franz.+ 4 1))))))
--
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, ·····@crcge1.cge.fr
From: Ken Dickey
Subject: Re: Translating Franz Lisp to Common
Date:
Message-ID: <4065@tekcrl.LABS.TEK.COM>
In article <····@cayman.cme.nbs.gov> ······@cme.nbs.gov (Tom Kramer) writes:
>
>I have translated a few hundred lines of Franz Lisp code into Common Lisp.
...
You might be interested in "Porting Pan I to Allegro COMMON Lisp",
Darrin Lane, Report # UCB/CSD 88/453, September, 1988 {U of Calif.,
Berkeley}. It describes a port of an 18000 line program from Franz
to Allegro and covers file & buffer i/o, keystroke handling, etc. and
has a set of example macros in the appendix. Not a panacea, but seems
a reasonable description of the issues.
-Ken Dickey