Book logo xindy

A Flexible Indexing System


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

Re: Xindy 1.2.1 and Allegro Common-Lisp (was: Xindy and Allegro Common-Lisp)



> 
> Roger Kehr <kehr@iti.informatik.th-darmstadt.de> wrote:
> : Bernd Raichle wrote:
> [...]
> : > Can you explain what the differences beetwen ``:input'' and
> : > ``:input-immutable'' are?
> : 
> : I borrowed this from the implementation of function `load' int the
> : CLISP-source :) I never asked if it is standard.
> 
> Bad practice!  Better change the :direction option of `open' option to
> the standard `:input'.

Already happend :)

> [...]
> : > - "markup.lsp"
> : >
> : >   When opening the `logfile' in function `do-startup' add the
> : >   keyword/value
> : >         :if-exists :overwrite
> : >   to the `open' function call.  The default for :if-exists is :error,
> : >   i.e. signal an error if file to be written exists.
> : >
> : >   Same change needed when opening the `output' file in this function.
> : 
> : CLISP did never report an error :)
> 
> This is a bug in CLISP (or the Lisp standard has changed once more?).
> Allegro CL reports an error if the log file existed which is the
> standard behaviour.

Yup. I see that CLISP seems to have many problems with the standard.
My problems is that I almost the whole time had the CLtL2 book next
to me, and I tried to program according to this "standard" and thus
many problems were introduced this way.

> : What about the (system::getenv "XINDY_SEARCHPATH") call in
> : set-searchpath-by-environment? Does it work on Allegro?
> 
> Ugh, no.
> 
> Allegro has a `getenv' function in package `sys', i.e.
> (sys:getenv "XINDY_SEARCHPATH") will work.

Is package `sys:' somehow aliased to `system'?

> No, it signals the following error (if done in the IDXSTYLE package):
> 
> 
> Error: keyword list (1 :LENGTH "}f." :CLOSE "folone{" :OPEN "follows" :CLASS)
>        should only contain keys (:LENGTH :CLASS :SEP :CLOSE :OPEN)
>   [condition type: PROGRAM-ERROR]

Ugh, that's it! The elements of the returned list are *not* in the
order of the original list. This is conforming to the standard saying
that

---
There is no guarantee that the order of elements in the result will
reflect the ordering of the arguments in any particular way. The
result list may share cells with, or be eq to, either of list-1 or
list-2, if appropriate. 
---

CLISP seems to have preserved this order and Gabors macro was
inadvertently assuming this. I have to write a function that does not
assume this behaviour, thus a set-difference preserving the order of
list-1.


Bye and have a nice weekend :)

-- 
======================================================================
Roger Kehr			   kehr@iti.informatik.th-darmstadt.de
Computer Science Department          Technical University of Darmstadt