This document proposes ideas to make the Larceny system more consistent and easier to use. (As of v0.93, much of this has been done; this page has been updated to reflect current status as of then.)

Installation

A larceny binary distribution should work wherever it is unpacked; a minimal setup script may be necessary, but none would be preferred. None is necessary as of 0.93. It would be best if the Larceny executables could figure out their location on disk and find other files as necessary from there. Two global parameters have been added:

  • current-larceny-root: String
  • current-require-path: List(String)

current-larceny-root should be the root directory of the larceny distribution, used to location default heap images and include files. current-require-path should be a search path for the larceny library (more below).

We determine larceny-root in a number of ways, in this order:

  1. an environment variable ($LARCENY_ROOT, %LARCENY_ROOT%)
  2. a path hard-coded in a batch file or shell script
  3. the path to the executable (in which case a warning is issues)

The parameter is modifiable from within the system; however, command-line arguments or environment variables should supersede anything set in ~/.larceny, and currently don't.

current-require-path is initially be derived from current-larceny-root, and may be extended by ~/.larceny.

Larceny should be able to override the system path when looking for external tools such as cc and nasm.

Compiling with Larceny

Compiling should be as similar as possible across the Larceny flavors. In binary distributions, the twobit executable/heap should be prepared to compile immediation upon invocation. This is somewhat improved now that we have Petit and IASN Larceny (user) heaps. I propose the following interface:

; compile foo.sch, output to foo.fasl and foo.{dll,exe,so}:
(compile-file "foo.sch")

; compile foo.sch, output to bar.fasl and bar.{dll,exe,so}:
(compile-file "foo.sch" "bar.fasl") ; output to bar.fasl ...

; compile {foo,bar,baz}.sch, output to qux.fasl and qux.{dll,exe.so}
(compile-file '("foo.sch" "bar.sch" "baz.sch") "qux.fasl")

In the one source form, the destination is optional. In the multiple source form, the destination is required. If we (define compile-files compile-file), this has the advantage that it subsumes both systems without being ambiguous. (We probably should unify it with Common Larceny's build-application as well.)

It would be great if we could find a way to combine fasl and so/dll into one file. On Windows, this actually presents a serious difficulty, since the current split makes it possible to compile a file while it's also loaded.

I'd also be interested in investigating moving the Intel assembler into Petit Larceny and generally making it work more like SPARC Native Larceny. IASN Larceny is this.

Testing

Test are currently fragmented, incomplete, out of date, and confusing. It subdirectory of source:trunk/larceny_src/Testsuite/ uses a different protocol for running tests and reporting errors, and it's very confusing. Some tests are commented out, and it's not clear why. Some tests don't pass, and it's not clear if they are supposed to.

We ought to be testing for R5RS compliance, not just R4RS. (And R6RS pretty soon...)

The test reporting in source:trunk/larceny_src/Testsuite/Lib/ is not bad; perhaps we should attempt to adopt it for all (or just more) tests.

A user, upon building from the source distribution, should be able to run all appropriate tests easily from the build environment. Something like (run-tests 'library 'compiler 'stress) or (run-tests 'all) would be nice. Maybe binary distributions should be able to do this as well.

Host support

We now support MzScheme 209 and 3xx, and it seems to build with Chez.

Bug tracking / Changelog

There is evidence that this was rational in the past, but I believe it's been lost. I think we need to use an actual tool. I don't have any in particular to suggest, but Trac was suggested to me. I don't trust its wiki, though maybe it's been improved, and maybe the Subversion support will be nice. We are now using Trac.

Libraries

We need to organize the library. It's big, and I don't think we want it all in the initial heap. I would appreciate some kind of "require" facility that looks for files in a search path. Additionally, it should load fasl files if available (and new enough?) and Scheme source files otherwise. We now have require, but it will likely be superseded by R6RS Libraries.

The binary distributions should come with compiled libraries that are easily loadable.

Building the Larceny system

It would be nice if this were as similar as possible for all three flavors:

> (load "Util/larceny-setup.sch")

Choices:

> (setup 'mzscheme 'win32)           ;; win32, default is stdc
> (setup 'larceny 'win32 'native)    ;; win32, using nasm
> (setup 'mzscheme 'win32 'common)   ;; win32, common larceny
> (setup 'mzscheme 'solaris)         ;; solaris, default native
> (setup 'mzscheme 'solaris 'petit)  ;; solaris, petit/stdc
> (setup-directory-structure)
> (build-config-files)
> (build-heap)
> (build-runtime)
> (build-runtime 'debug)             ;; common only?  
                                     ;; FSK: runtime has "NDEBUG" directives 
                                     ;; that would be useful to control here.

Petit only, I suppose:

> (build-executable)
> (build-twobit)

We've had some movement in this direction, but building Common Larceny is still very different.

Currently, packaging it up for distribution is painful and messy. It's improved by the directory restructuring, but it should be even easier to create a distribution package identical to what we distribute.

> (package 'tar)
> (package 'zip)
> (package 'msi)
> (package 'src)