[Top][All Lists]

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

Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian

From: Gabriel Dos Reis
Subject: Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian
Date: Thu, 06 May 2010 02:22:33 -0500

Faré <address@hidden> writes:

| >>>: Gabriel
| >>> I rather use a command line option than having 4 or 5 versions of GCL
| >>> executable, all essentially the same.
| >>>
| >>
| >> Or environment variable?
| >
| > that would do too -- though my preference would be for a command line 
| >
| You could have both, with a central script having its defaults,
| and thin wrapper scripts overriding it:
| #!/bin/sh
| exec gcl_dispatcher -cvs -ansi "$@"

If all one has is scripting, yeah.  But, when I'm configuring OpenAxiom for
build with GCL, I rather deal native executables (e.g. on Windows) than
dealing with scripts that look for god knows what environment variables
for CL conformance.  Wrapping GCL executable in scripts drascically
limits how applications built on top of GCL can be delivered to
end-user -- yes, one could go and use your cl-launch that would try to
abstract over the intricacies, but why make it sufficiently painful so
that cl-launch is needed? 

I guess, the real question is why would GCL-2.7.x need to have myriad
variants?  SBCL, ECL don't.

| >>> note that defpackage is atually a separate package in GCL, that
| >>> sometimes causes troubles if you don't use the package defpackage.
| >> Is this a problem?
| CLHS says that all symbols documented in the CLHS and only them
| should be exported symbols of the CL package, but explicitly allows
| the home-package of any such symbol to not be CL. According to my .sig,
| GCL 2.7 seems to be compliant.

The issue is how convenient it is for the end-user, not theoretical

| > compared to the default behaviour of other free Lisp, yes.
| > It can be quite confusing and eat up precious time, when one is unaware
| > of that behaviour.
| >
| I'm not sure - what eats precious time? I'm more confused by the way
| that defpackage doesn't work well in an eval-when than by the fact
| that it lives in a different package.

are you sure the two issues are completely orthogonal?

| Note that you could have the defpackage package import defpackage from CL
| instead of the opposite.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]