Subject: [clisp-list] funcall

From: Myriam Abramson <[email-masked]>
Date: Fri Jan 18 07:46:02 2002

Hi!

Maybe you have a suggestion. I'm porting some code from allegro to
clisp and clisp gives me an error here: 

(FUNCALL #'(LAMBDA (x6)
	      (PROVE X7 (SETOF N2 OBJECT (AN-STG ((NEAREST))))
                            (PREDICATE :AGENT X6 :TO-LOC X7))))

*** - SYSTEM::%EXPAND-FORM: (NEAREST) should be a lambda expression

Prove and setof are macros and they work fine at the command line with
the same arguments. Unfortunately, I can't change the code that
produce this expression so any suggestions is welcome. 

-- 

                                    myriam

---

From: Sam Steingold <[email-masked]>
Date: Fri Jan 18 08:42:10 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] funcall"
> * Sent on 18 Jan 2002 10:41:45 -0500
> * Honorable Myriam Abramson <[email-masked]> writes:
>

what do

        (SETOF N2 OBJECT (AN-STG ((NEAREST))))
and

        (PROVE X7 (SETOF N2 OBJECT (AN-STG ((NEAREST))))
                  (PREDICATE :AGENT X6 :TO-LOC X7))

macroexpand to?

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
If it has syntax, it isn't user friendly.

---

From: Kaz Kylheku <[email-masked]>
Date: Fri Jan 18 11:25:26 2002

On 18 Jan 2002, Myriam Abramson wrote:

> Date: 18 Jan 2002 10:41:45 -0500
> From: Myriam Abramson <[email-masked]>
> To: [email-masked]
> Subject: [clisp-list] funcall
> 
> 
> Hi!
> 

Without your revealing what these macros can do, it's very hard to guess.
You are asking people to hyptohesize about code that is completely
unknown to them.

The first thing to do is to look at the evaluation stack
to find out how the evaluation arrived at that error. There
are debugging commands for doing that, just type ? for help.

Then inspect the expansion of these macros with macroexpand, to see
what the macro expander does with the structural element (NEAREST).

> produce this expression so any suggestions is welcome. 

As a rule of thumb, when you port code, you have to be prepared to change
it so that it works on the new platform, while continuing to work on the
old ones.  If you can't do that, you can't do porting; the constraint
you are faced with is simply unrealistic.

Consider that by running the program on a different platform, you are
*effectively* changing it, because you are replacing the entire Lisp
layer with a different implementation. If that risk is okay, why is it
not okay to adjust the code?

You can always use #+ and #- to introduce implementation-specific
variations to code. Say you have some form F which works great on your
currently supported Lisps but needs to be written differently on CLISP,
as the new form F*.  So then you can replace F with

    #-CLISP F	; on anything but CLISP, read form F
    #+CLISP F*	; on CLISP, read form F*

This way you did change the source file, but you did not introduce any
change to the objects that are read from it.

If even that risk is unacceptable, at least not in the short term,
then what you can do is fork the project to create your own code stream
targetting CLISP. The version control tool CVS can do this quite easily
with its vendor branching feature; you can import some ``third party''
code, and make local modifications of it.  The later you can import
newer snapshots of the code and merge them with your local mods.

If you are already using a version control tool that supports reasonable
branching, then you can just start an experimental branch. Others don't
have to accept your changes until you put them through whatever
verification process your organization requires; in the meanwhile
you can live on your branch.