Franz Lisp on NetBSD

[krytarowski]

There is a port of Franz Lisp to NetBSD 0.9:

http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html

These unmodified executables still run flawlessly on NetBSD 7.99.72.

There is also a work in progress port maintained by Christos Zoulas for modern NetBSD (and possibly other BSDs/Linux). It works on i386, vax, m68k, mips, amd64:

http://www.netbsd.org/~christos/franz.tar.gz

[omasanori]

Thank you for informing me!
When I made this repository, I just wanted to put it as-is for reference. However, it may be better if it actually runs on our machine without original BSD tapes + VAX (?) simulator. I'll take a look at the ports.

[krytarowski]

This is on my NetBSD desktop:

chieftec$ uname -a
NetBSD chieftec 7.99.72 NetBSD 7.99.72 (GENERIC) #32: Sat May 20 01:00:52 CEST 2017  root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64
chieftec$ date
sob. maj 20 03:21:57 CEST 2017
chieftec$ ./lisp
Franz Lisp, Opus 38.92
-> (cons 1 (cons 2 3))
(1 2 . 3)
-> '(1 2 3 4 5)
(1 2 3 4 5)
-> (+)
0
-> (*)
1
->

I'm running the prebuilt binaries from NetBSD/i386 0.9.

There is need to enable compat for these files in the kernel.

$ config -x /netbsd|grep COMPAT                                                                                              
options         COMPAT_NOMID    # NetBSD 0.8, 386BSD, and BSDI
options         COMPAT_09       # NetBSD 0.9,
options         COMPAT_10       # NetBSD 1.0,
options         COMPAT_11       # NetBSD 1.1,
options         COMPAT_12       # NetBSD 1.2 (and 386BSD and BSDI),
options         COMPAT_13       # NetBSD 1.3 (and 386BSD and BSDI),
options         COMPAT_14       # NetBSD 1.4,
options         COMPAT_15       # NetBSD 1.5,
options         COMPAT_16       # NetBSD 1.6,
options         COMPAT_20       # NetBSD 2.0,
options         COMPAT_30       # NetBSD 3.0,
options         COMPAT_40       # NetBSD 4.0,
options         COMPAT_50       # NetBSD 5.0,
options         COMPAT_60       # NetBSD 6.0, and
options         COMPAT_70       # NetBSD 7.0 binary compatibility.
options         COMPAT_43       # and 4.3BSD
#options        COMPAT_386BSD_MBRPART # recognize old partition ID
options         COMPAT_OSSAUDIO
options         COMPAT_NETBSD32
options         COMPAT_LINUX
options         COMPAT_LINUX32  # req. COMPAT_LINUX and COMPAT_NETBSD32
options         COMPAT_BSDPTY   # /dev/[pt]ty?? ptys.
options         IPFILTER_COMPAT # Compat for IP-Filter
options         WSDISPLAY_COMPAT_PCVT           # emulate some ioctls
options         WSDISPLAY_COMPAT_SYSCONS        # emulate some ioctls
options         WSDISPLAY_COMPAT_USL            # wsconscfg VT handling
options         WSDISPLAY_COMPAT_RAWKBD         # can get raw scancodes

The default config is in /usr/src/sys/arch/amd64/conf/GENERIC, to rebuild:

./build.sh tools
./build.sh kernel=GENERIC

C liszt starts too:

$ ./liszt
Liszt C version 8.39.spottisport [.92]
->

However not everything is that pretty, there is currently a problem to bootstrap the standard library, so Franz Lisp is bare bone. To bootstrap it there is need for a.out toolchain, NetBSD 0.9 does not exist anymore as AT&T lawyers forced us to drop it (BSD vs AT&T wars). I was trying to configure toolchain from NetBSD 1.0 on my NetBSD-current machine, but there were some bugs detected and I will need to report them first.... (another option is to use a machine simulator for NetBSD 1.0).

The Christos' work is a maintenance and as far as I can tell it's still the bare Franz Lisp without Liszt. I think there is undumping in a.out format involved (something similar is used by Emacs nowadays).

I don't get the claim that these sources are "Public Domain", I expect they are treated like "abandonware", however they have clear statement that they are: BSD-4-clause licensed & no AT&T copyright infringement; and the NetBSD 0.9 work snapshot by Jeff Dalton from 1994 licenses Liszt (C target) as NonCommercial (so NonFree).

Can we get Macsyma for Franz Lisp, if so where? It was the primary user as far as I can tell. It could help to verify correctness of Franz on modern computers.

[krytarowski]

I've created a dedicated repository for Franz Lisp work by Jeff Dalton:

https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386

Its only purpose is to preserve it.

[omasanori]

Thanks for detailed information. Yes, some works will be needed for making full tool chain work out-of-box.

The source of "public domain" is http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/others/franzlsp/op38_93b/0.html but it might be safer to assume it is licensed under BSD-4.
Note that the third clause (advertising clause) of the 4-clause BSD license is no longer effective at least for the Berkeley Software Distribution, so we can treat the code as it is licensed under the 3-clause BSD license (an OSI-approved and GPL-compatible license, yey!) AFAIK. IANAL; TINLA ;-)
See ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change for details.

Sorry, I have no idea about Macsyma on Franz Lisp. I hope it is still preserved in someone's tape but I haven't found public one on web yet. We might be able to get old DOE Macsyma but it is not for Franz Lisp but for NIL.

[krytarowski]

I had no idea that Berkeley relicensed the software.

My goal is to make it usable, and keep the latest BSD version runnable and verified as correct. I have some pipe dreams to learn frontends and recreate from scratch a newer version based on LLVM. This would eliminate the C-Liszt show-stopper with the license, restriction to a.out and restriction to certain backends.

I'm personally distasted with CL as overengineered, I feel like Scheme is academic and Franz is the world between them two - compact and featured, without (in my taste) craziness of CL. I would like to revive it. Also as a NetBSD developer I noted sentiment from some older staff about Franz Lisp (as it even happened to be privately maintained). I'm thinking about making the NetBSD 0.9 version as model for my play, it's a fork of BSD 4.2 one.

Thanks for collecting information about this Lisp.

[omasanori]

Fantastic!
I have some interest on Lisp dialects (and Lisp machines) in "before Common Lisp" era too.
Franz Lisp with LLVM back end sounds really great. (GHC's LLVM back end may be interesting if you don't want to play with API/ABI breakage of LLVM; as a former contributor of Rust, I feel that the breakage is a real problem for compiler developers.)

[krytarowski]

I see, so this might be the reason why frontend examples are in.. OCaml.

For portability reasons the only choice is C/C++. Rust or GHC are eternal issues on less mainstream platforms like NetBSD, and we actually need help with rust in order to retain Firefox. For example Firefox/sparc64 maintainer is close to give up with Firefox due to rust dependency.

I'm also thinking about embedding the standard library directly into the language itself and not depend on external files (like in the original BSD Franz Lisp).

Compatibility issues? There is an option to donate the code to LLVM people and attach buildbot, so they will be responsible to address breakages.

[omasanori]

Ah, my suggestion is not to rewrite the whole things in Rust or Haskell, but to output LLVM assembly code instead of linking with libLLVM*.so (or .a), which is the main idea of GHC's LLVM back end.
I'm sorry if I misled you.

[krytarowski]

I see, interesting.. I gave it a try and LLVM C++ API is tolerable. It also increases chance to donate it to LLVM in future.

[omasanori]

Great!
Sadly I don't have enough time to work on porting right now, so I will mention porting efforts by you and others in README instead for now. Thanks a lot again for your information.

[krytarowski]

Please don't announce rewrite it before a functional demo... it will take a while.

[omasanori]

I see.

[omasanori]

I have done nothing yet, but clarified the license.

[krytarowski]

I took the code from ~1982 as perhaps the most original one and I was trying to port it to modern NetBSD. However it happened to be close to impossible, because everything is hardcoded on hacks like size of some sections in file. My impression was that it is better to start from scratch.

I was playing with pc-lisp, I've ported it to NetBSD and packaged in pkgsrc. It's like Franz Lisp, but with some distinct differences.

The LLVM-backend idea has pros and cons.. it's very heavy libraryset and even just linking anything against that is a cost. Also their API/ABI is unstable and costy.

I've managed to import the Franz Lisp book by Wilensky from the U.S. and I was studying it.

No big news on my side, but it's not dead.

[krytarowski]

I was trying to start writing or rewriting Franz Lisp from scratch few times, but not went into anything functional so far. I will keep trying until completion.

[larsbrinkhoff]

For your information, we have an almost complete set of Macsyma files for Maclisp running on ITS. Since Franz Lisp has a Macsyma compatability mode, and Macsyma has many conditionals for FRANZ, it may be possible to get it running.

[krytarowski]

Franz is a portable version of next generation Maclisp.

[krytarowski]

@larsbrinkhoff can you share it? Berkeley macsyma was at some point of time open-sourced..

[larsbrinkhoff]

It's in here: http://github.com/PDP-10/its

It's hard to say where, exactly, because the source files are scattered over many directories and intermingled with personal files.

[larsbrinkhoff]

However, the expect script build/macsyma.tcl should be a good starting point for figuring out which files are involved.

[krytarowski]

BTW. I have noted a Franz lisp book in PDF on libgen now (LISPcraft by Robert Wilensky).

[omasanori]

Closed for now. (See https://github.com/omasanori/franz-lisp/issues/3#issuecomment-716600458 for context.)