>>>: 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 option. > You could have both, with a central script having its defaults, and thin wrapper scripts overriding it:
#!/bin/sh exec gcl_dispatcher -cvs -ansi "$@" >>> 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 11.1.2.1 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. > 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. Note that you could have the defpackage package import defpackage from CL instead of the opposite. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] (labels(({(] &rest [)(apply([ ])[))([(>)(elt(]())>))(](<)(do-external-symbols(] :cl)(push ] <))(sort <`string<`:key`string))(}({ + ^)({`816`1/5)({`688({`875({`398()"~{~A~^ ~}"(]())){(+ { +)))({`381)^))(do*(({`5248({`584 }`36063))([`874({`395 {`6))(]`4({`584 {`6))(}`#36RH4G6HUTA1NVC1ZHC({`395 }`36063)))((} [ ] ({`977 ]))({`902)({`381)))) _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel