[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SML-NJ Package Names

On Tue, Jan 14, 2003 at 08:06:31PM -0800, Aaron Matthew Read wrote:
> I am working on a repackaging of the SML/NJ package that splits the
> sml runtime component apart from the sml compiler. The idea is to
> facilitate the packaging of SML programs and libraries without
> requiring the user to install the compiler. 

An excellent decision.

> My main question is how to name these packages appropriately. Here is the
> package naming as of now:
>   smlnj-runtime : the runtime system
>   smlnj : the compiler
>   ml-yacc : sml yacc implementation
>   ml-lex : sml lex implementation
>   ml-burg : a code generator generator
>   smlnj-lib : misc libs for sml
>   ckit : translate C code to an abstract syntax in SML
>   exene : an X11 programming interface for SML
>   ml-nlffi : the "No Longer Foreign Function Interface"
>   cml : Concurrency support for ML.

Are these SML/NJ specific?  It might be a good idea to prefix them if
they are.  Even if they are not, perhaps an sml- prefix would be in
order, much like CL packages are prefixed with cl-.  A crude
namespacing, but it could help.  It's debatable whether non-development
related applications should have the prefix, but libraries and whatnot

> Besides the "smlnj-runtime" and "smlnj" packages, all others are named
> the same as they are upstream.

This is somewhat nice, but I don't think that namespace conflicts are
worth having the same name as upstream, if it might be a problem.

> Any comments on this naming scheme. Should the "smlnj" package be
> called "smlnj-compiler"?

When I did this for bigloo, I chose bigloo and bigloo-runtime, but the
latter package was merely a branch off of the runtime libraries; not a
major package restructuring.  I think that this is fine, SML/NJ is a
compiler and I would expect the sml-nj package to have the compiler.
The -runtime bit is for other packages to depend on, and would probably
never be directly installed by a user.

One thing you might want to think about is how to play nice with future
versions.  In other words, if a future version's runtime is not
backwards compatible then you will have to arrange a separate package
with separate directories.  Possibly even a package name with version
information, if you want to be able to have both versions installed
simultaneously.  sml-nj-runtime110.42, etc.

One little thing: why smlnj instead of sml-nj, as before?

; Matthew Danish <mdanish@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."

Reply to: