Alexander Burger wrote:
> Hi Cle,
>
Hi Alex,
(...)
>> 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).
>
This is ok, I think! Only it would be nice, if the reference manual
would describe more clearly what is going on and what is dangerous. But
perhaps with time I get more used to picoLisp, I can help a bit with the
documentation.
> 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.
>
Not meant as critique, but jumping to a non-sense function pointer
thereby killing the picoLisp process has another quality for me, than
calling 'unify' for instance outside a Pilog clause and get a SEGFAULT
for that blasphemy. The latter could be detected by the interpreter,
IMO. But this does not mean, I write a ticket against this "feature". I
will learn to cope with it :-)))
> Instead, PicoLisp encourages a defensive interactive development style,
> with tracing, debugging and introspection tools.
>
So does Erlang, Smalltalk, Ruby and a lot of other languages as well
IMO! So perhaps you would state, that picoLisp "require" a defensive
style? ;-)
>>> 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.
>
Ok, I see! But this was only for explanation purposes of 'findall'. In
reality the query to 'findall' could be as well something like:
All ways from this certain signal backwards until a end-of-tracknet
was reached.
Once got those ways, something could be done with them, e.g. check, that
there will be a preceding signal on every way announcing that certain
signal in question.
So it would not only be a query like that I formulated in my ascii
example, but a much more complicated one!
>> 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.
>
Yeah, I think you are right! But what could be the name of such a lib?
Until now, we have two such clauses gotten 'retract' and 'findall'.
Those would be Prolog compatibility functions. But calling it "prolog.l"
.. :-/
> Cheers,
> - Alex
>
Ciao,
cle.
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
