Hi Cle,

> hmmm ... then let me make the statement, that picoLisp is also, ahh ...,
> "different" from other interpreted languages here.

True :-)

> The most languages
> try the hell to avoid such ugly things like a SIGSEGV or SIGBUS ;-)

PicoLisp doesn't want to do that. After all, these are "error messages",
resulting from hardware runtime tests, optimal in terms of efficiency
and reliability. A language cannot check for every possible error
situation anyway (think of the halting problem).

And PicoLisp can't do that without losing flexibility or efficiency. In
this regard it behaves like C. You can easily crash PicoLisp, for
example, by jumping to an arbitrary memory location (function pointer).
I think this is acceptable, and not a problem in practical work.

Instead, PicoLisp encourages a defensive interactive development style,
with tracing, debugging and introspection tools.

> > But the above version ('make' or 'solve') also calls Lisp ;-)
> Yeah! But this is only one place, where Lisp is being used. And the
> whole Pilog will get the the possibility to search for all solutions of
> a query without implementing the query in Lisp :-)

Ah, I see. I was thinking to implement 'findall' via the 'T' property.
This seemed easier, and more efficient, because the requested list is
already there without any further processing.

> Ah, this is understandable. I fear I was unclear, though! My question
> should be, if 'findall' has a chance to get into the official picoLisp
> implementation ("misc/pilog.l" would be ok), or whether I have to reside
> the implementation in my own library?

If you collect more such useful predicates, we should think about the
name of such a library. I wouldn't use "misc/pilog.l", because in
"misc/" there are simple tests and arbitrary little projects, but no
libraries. It should better be some "lib/xxx.l" for Pilog extensions.

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to