Hi Abel,
On Sun, Jan 20, 2019 at 02:40:58PM +0300, Abel Normand wrote:
> I did some tests and I am feeling confused atm.
> ...
> (de pg-trans X
> (run X 1) )
So 'pg-trans' is equivalent to plain 'run'.
> (de execute-eval @
> (mapcar eval (rest)) )
This function evaluates its arguments twice. It is called after *all* arguments
are evaluated and are available via (next), (rest) etc. It then builds a list of
all these results with (rest), then maps over this list 'eval'uating the values
a second time.
Thus,
> [execute-eval
> '(assert-throws 'myerr
> (pg-trans (myerr-fun)) )
such a value after the first evaluation is the list
(assert-throws 'myerr (pg-trans (myerr-fun)))
which upon second evaluation executes (myerr-fun).
> (de execute-run X
> (run X 1) )
'execute-run' is a plain 'run' again.
Hmm, sorry, I'm getting confused ;) Many variations of similar pieces of code.
I'm not sure exactly for which purpose you did all these tests.
> So its seems like unevaluated fargs always keep track of their environment
> and work as intended.
Which part of them did you suspect not to work as intended?
> Then I do not understand my issue in tests of pgint.l in one specific case
> when I have to test exception thrown inside of (pg-trans). When I write
> code that *will* throw and exception and I run it outside of
> aw/picolisp-unit (execute) function it is catched and treated as intended.
> But when I run corrupted (pg-trans ...) *inside* of (execute) function it
> stops with "pg-db-err -- Tag not found".
I'm lost a bit where exactly it went wrong. But the reason must surely be a case
where a (throw 'pg-db-err) is done outside a matching 'catch' environment.
> But when yesterday I tried to rewrite (execute) to use (run) for evaluating
> fargs I met the same error, surprisingly.
I would single step through the code with (debug 'fun) or manually placing '!'
breakpoints and looking at the environments of the breakpoints in the
breakpoint's REPL with (bt) etc.
> Probably Im missing something?
Not sure. I think your setup is too involved and over-abstacted.
Also, in general, I would not recommend
(catch 'sym
...
(throw 'sym ..)
... )
for *error* handling. Traditionally, catch/throw in Lisp is for non-local
*jumps*, not so much for errors or exceptions.
In PicoLisp it is more natural to let the system issue implicit errors, or issue
them explicitly with (quit "Message" Value), and then let the application code
do with them whatever it wants, or to catch them with
(catch '("Message")
...
or
(catch '("Message1" "Message2" "Message3")
...
or even
(catch '("")
...
to catch them *all*.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
