Subject: [clisp-list] clisp port of cl-xml

From: james anderson <[email-masked]>
Date: Sat Aug 16 11:18:10 2003

hello again;

i'm still inching forwards with compiling cl-xml on clisp and i have a 
few more questions. none of the observations are new, it's just that it 
would be nice to be able to guage how much time this is going to take, 
and some idea of whether there might be plans to address any of these 
issues in the near future - or one the other hand how intrinsic they 
are to clisp, might give me an idea of whether it is worth spending the 
time adapting to them

1. logical pathnames :

as per earlier correspondence, translation must be expressed with 
exactly the correct components as the object. is there any chance that 
this will change?

2. documentation does not accept a package, is not a generic, and there 
is no setf.

i've taken to redefining it, but it is not clear what idiom the 
compiler requires. i do not really want to do it at compile time, but 
i've yet to succeed at getting a redefinition wrapped in an 
ext:without-package-lock form to compile.

3.metaclass defnitions require a (:metaclass structure-class)

i noted this in an earlier message, is this correct?

4. defclass does not support forward references

if could see this between compilation units, but it's really an 
inconvenience within a single file. it makes it difficult to lay out 
definitions in alphabetical - or some other lexically convenient  - 
order, without running afoul of the restriction. any prospects for 
improvement?

5. only the standard method combination

it is easy enough to avoid defining new method combinations for the 
time being, but it's not very productive to not have the simpler 
combinations like and, or, progn. any prospects for improvement?

those are the issues i've noticed at about 50% through. i can't get 
much further without a workaround for method combinations, and it makes 
sense to ask what the future might look like before i do anything 
further.

i'd appreciate any insights anyone has about these - and other - 
conformance issues before i proceed much further.

thanks,
...

---

From: Sam Steingold <[email-masked]>
Date: Sat Aug 16 18:53:12 2003

> * In message <[email-masked]>
> * On the subject of "clisp port of cl-xml"
> * Sent on Sat, 16 Aug 2003 20:11:45 +0200
> * Honorable james anderson <[email-masked]> writes:
>
> few more questions. none of the observations are new, it's just that
> it would be nice to be able to guage how much time this is going to
> take, and some idea of whether there might be plans to address any of
> these issues in the near future - or one the other hand how intrinsic
> they are to clisp, might give me an idea of whether it is worth
> spending the time adapting to them
> 
> 1. logical pathnames :
> 

I am not sure CLISP is non-compliant here.
Other implementations might be providing an extension.
Patches are welcome.

> 2. documentation does not accept a package, is not a generic, and
>    there is no setf.

fixed in the CVS.

> i noted this in an earlier message, is this correct?

CLISP is indeed not compliant here: STANDARD-OBJECT is supposed to be a
STANDARD-CLASS and it is actually a STRUCTURE-CLASS.

I am not sure how to fix this.

> 4. defclass does not support forward references

fixed in the CVS

> it is easy enough to avoid defining new method combinations for the time
> being, but it's not very productive to not have the simpler combinations
> like and, or, progn. any prospects for improvement?

Bruno said earlier this year that he was thinking about adding this
feature, but I am not sure how far he got with it.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Is there another word for synonym?

---

From: james anderson <[email-masked]>
Date: Sun Aug 17 05:39:13 2003

in summary, it appears that it would be wise to build the latest source.

as my most recent serious experience with shell scripts predates clisp, 
i would benefit from more elaborate hints as to how to approach the 
problem with the syntax specification which i noted in an earlier post.
? where could one specify "darwin" v/s "darwin6.6" v/s one of the other 
values in the displayed case statement?
? which shell script is actually exhibiting this problem?

> I am not sure CLISP is non-compliant here.

my interpretation is that it devolves down to pathname-match-p, which 
is defined to interpret any missing components as if they were :wild. 
which means that "**;*"  should be treated the same as "**;*.*.*".

> Other implementations might be providing an extension.

first i have to get it to compile.

>> 2. documentation does not accept a package, is not a generic, and

ok.

what about the second part of the question: how to redefine functions 
in a locked package in a file-to-be-compiled?
is there an alternative to globally unlocking the package?

without regard to the state documentation support, i do this with 
functions which some implementations make generic but others do not. 
things like stream-element-type and simple-confition-format-*. i 
realize it is non-conformant to do this, and i noted when reading your 
clos code that it appears that clisp tracks those functions what are 
specified to be user-extensible, but i would like to maintain the 
practice none-the-less, so i would appreciate any advice as to how to 
do so "properly" in clisp.

> STANDARD-CLASS and it is actually a STRUCTURE-CLASS.

i just #+ it. it only matters whether i'd need to make it clisp version 
dependant.

>> 4. defclass does not support forward references

ok.

>> time

as in interim approach, just so i don't need to rewrite my generic 
function definitions, i'd be tempted to factor support for the 
predefined operator combinations out of 
clos.lisp#compute-effective-method, without adding any support for 
defining new combinations.

...

---

From: Sam Steingold <[email-masked]>
Date: Mon Aug 18 11:29:02 2003

> * In message <[email-masked]>
> * On the subject of "Re: clisp port of cl-xml"
> * Sent on Sun, 17 Aug 2003 14:37:52 +0200
> * Honorable james anderson <[email-masked]> writes:
>
indeed.

> ? which shell script is actually exhibiting this problem?

no idea.
Bruno?

> is defined to interpret any missing components as if they were
> :wild. which means that "**;*" should be treated the same as
> "**;*.*.*".

OK, I fixed this in the CVS - please try the head.

> what about the second part of the question: how to redefine functions in
> a locked package in a file-to-be-compiled?

you should never globally unlock a package (unless you are a CLISP
developer).

when do you get this package lock error?
I don't quite understand what you are doing.
a small code snippet might help.

> i just #+ it. it only matters whether i'd need to make it clisp
> version dependant.

Bruno, maybe it would made sense for the metaclass option to default to
the (common!) metaclass of the superclasses?

> defining new combinations.

again, patches are welcome (the more general the better ;-))

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Lisp: it's here to save your butt.

---

From: james anderson <[email-masked]>
Date: Mon Aug 18 12:27:03 2003

On Monday, Aug 18, 2003, at 20:27 Europe/Berlin, Sam Steingold wrote:

>> in
when i try to compile a file which attempts to redefine a function in 
the common-lisp package.
i just looked through the functions this applies to, and observe that 
but for documentation, they are cmucl-family specific and don't even 
apply to clisp. if i use the cvs, then the problem with documentation 
is no more and the issue is moot.

SIMPLE-CONDITION-FORMAT-ARGUMENTS
SIMPLE-CONDITION-FORMAT-CONTROL
SIMPLE-CONDITION-FORMAT-STRING
STREAM-ELEMENT-TYPE
DOCUMENTATION (and setf)

> a small code snippet might help.

for the record, i wasn't doing anything special. just

(ext:without-package-lock
  ()
  (warn "disable lock on common-lisp: ~s" (ext:package-lock 
(find-package :common-lisp)))
  (let ((def (fdefinition 'documentation)))
    (unless (typep def 'generic-function)
      (warn "redefining ~s" def)
      (fmakunbound 'documentation)
      (defGeneric documentation (datum &optional type)
        (:method ((datum t) &optional doctype) (funcall def datum 
doctype)))))))

both with no package designators and with :COMMON-LISP.

> again, patches are welcome (the more general the better ;-))
if the approach sounds reasonable, no problem - once i can build it.

...

---

From: Sam Steingold <[email-masked]>
Date: Mon Aug 18 13:37:03 2003

> * In message <[email-masked]>
> * On the subject of "Re: Re: clisp port of cl-xml"
> * Sent on Mon, 18 Aug 2003 21:25:17 +0200

err, the least generality we should go for, I think, is the short
version of DEFINE-METHOD-COMBINATION.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
UNIX is as friendly to you as you are to it. Windows is hostile no matter what.