RE: [Gcl-devel] ["GordonShawNovak"<address@hidden>]Re:GCLgetting slushy ...

[Mike Thomas]

Hi Camm.

| Actually, to my understanding, the inclusion of the gpl'ed binary
| components puts the whole binary "combination" under the GPL.

Yes.  It wasn't until I saw your checked in version of the message last
night that I realised what you were getting at - 100% correctly.


|  You
| might want to checkout the behavior of (si::default-system-banner)
| (just committed) and its behavior with different values in
| *features*.  Please let me know if something is amiss or undesirable.


|
| > | > I also would like to see, for the sake of convenience, the
| > | version displayed
| > | > as "2.6.1 ANSI" or "2.6.1 CLtL1" depending on the value of the
| > | configure.in
| > | > variable @CLSTANDARD@ which is already being used in the
| > | Windows installer
| > | > script to generate differentiable package names.
| > |
| > | Agreed.  Will do this, but how about tying to :ansi-cl in *features*?
| >
| > Agreed - I hadn't realised there was such a symbol until you
| mentioned it
| > thanks.  So I suppose we should also have a feature :CLTL1.  I say this
|
| I support this should be mutually exclusive with :ansi-cl, right?
| Even though except for a few instances, the former is built upon the
| latter.

I think so and likewise any further standards related symbols.


|
| > because according to stuff on one of the Corman CL lists it
| seems that there
| > may be a move to revise the CL standard under the auspices of the
| > Association of Lisp Users rather than ANSI mainly for administrative
| > reasons.  In other words we could conceivably be looking at a modified
| > standard within a few years.
|
| Wow.  I certainly hope not.  It takes years and years just to fully
| comply with what's already written.  Its also an asset to CL, IMHO,
| that a standard exists which is old and established.  Its really not
| old enough in my opinion.

>From where I stand the modifications required to clean up pathnames (for
example) are quite urgent.  They also appear to have dropped the ball on
important things like the FFI.

My understanding from lurking on email lists is that it will be
prohibitively expensive to work through ANSI, which is not good for
relatively small CL vendors.  Also note that languages like Scheme, SML and
Haskell have managed quite happily without an ANSI rubber stamp by
publishing documents in various ways with varying degrees of interest group
scrutiny and accord.

| There has been too much damage due to
| implementation diversification.

Agreed.  I suspect that much of the diversification is a function of defects
in the ANSI standard combined with the loss of drive and energy by
implementors and other interest groups somewhere between CLtL1 and the
present.


|
| >
| > I think it might also be smart to have a version feature as GCL
| itself is
| > rapidly changing and we could easily end up with a nasty mess
| in third party
| > code over the next two years.
| >
|
| We have si::*gcl-{major,minor,extra}-version*.  Do you feel something
| in *features* is better?

I think it is easier to conditionalise code with #+/- and let's face it,
that's what it is there for.  I notice that at least one large vendor does
this - note the existence of the implementation name and of that name
concatenated with the major version number and also the complete version
number:

CL-USER 1 > *features*
(:LISPWORKS-PERSONAL-EDITION :DBCS-ENV :COMPILE-REVERSE :BYTE-INSTRUCTIONS
HARP::PC386 :COMMON-LISPWORKS :COMMON-DEFSYSTEM :CAPI-TOOLKIT :CAPI
:LW-EDITOR :COMMON-FFI :NEW-PATCH-SYSTEM :DBCS :UNICODE :WIN32 :IAPX386
:FLOAT :CLOS :ANSI-CL :COMMON-LISP :LATIN-1 :LISPWORKS :LISPWORKS4.3
:LISPWORKS4 :HARLEQUIN-COMMON-LISP :HARLEQUIN-PC-LISP :NEW-PC-COMPILER
:COMPILER :REVERSE :LITTLE-ENDIAN :CLASS-SHAKE-USING-GATES
:SUPPORTS-CONS-BLOCKS :IEEE-FLOATING-POINT :FLI-REGISTER-MODULE)

This allows a programmer to set the level of granularity to the exact level
required using the appropriate tools; #+/-.

| > Note also in relation to standards
| >
|
| ???

Could have fallen asleep at the keyboard, could have been interrupted - it's
all too far away now!

Cheers

Mike Thomas.