I did some tests and I am feeling confused atm.
```
(de pg-trans X
(run X 1) )
(de execute-eval @
(mapcar eval (rest)) )
(de execute-run X
(run X 1) )
(de assert-throws (Type . Prg)
(prinl (catch Type (eval Prg))) )
(de assert-throws-q (Type Prg)
(prinl (catch Type (eval Prg))) )
(de assert-throws-t Prg
(prinl (catch T (eval Prg))) )
(de assert-throws-myerr Prg
(prinl (catch 'myerr (eval Prg))) )
(de myerr-fun ()
(throw 'myerr "EXIT") )
(prinl "EXECUTE EVAL")
[execute-eval
'(assert-throws 'myerr
(pg-trans (myerr-fun)) )
'(assert-throws-q 'myerr
'(pg-trans (myerr-fun)) )
'(assert-throws-t
(pg-trans (myerr-fun)) )
'(assert-throws-myerr
(pg-trans (myerr-fun)) )]
(prinl "EXECUTE RUN")
[execute-run
(assert-throws 'myerr
(pg-trans (myerr-fun)) )
(assert-throws-q 'myerr
'(pg-trans (myerr-fun)) )
(assert-throws-t
(pg-trans (myerr-fun)) )
(assert-throws-myerr
(pg-trans (myerr-fun)) )]
(bye)
```
```
->
[abel@abel-pc picolisp-playbook]$ pil uneval-fargs.l +
EXECUTE EVAL
EXIT
EXIT
EXIT
EXIT
EXECUTE RUN
EXIT
EXIT
EXIT
EXIT
```
So its seems like unevaluated fargs always keep track of their environment
and 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".
At first I thought that the cause of this error in quoting requirement for
test-cases. So in order to run test cases you have to run:
```
[execute
'(assert-t ...) ]
```
Execute function looks like this:
```
[de execute @
(mapcar eval (randomize (rest) ]
```
But when yesterday I tried to rewrite (execute) to use (run) for evaluating
fargs I met the same error, surprisingly.
Then I thought that the case probably with (assert-throws) function where
testbody executed with (eval):
```
[de assert-throws (Type Error Result Message)
(let Result (catch Type (eval Result) NIL)
(if (= Error Result)
(passed Message)
(failed Error Result Message) ]
```
But I tested similar behaviour in my test above and it seems correct.
After that I played a little with test case itself:
```
'(assert-throws 'pg-db-err NIL
'(pg-trans
(catch 'pg-data-err (pg-execute "SELECT 1/0;"))
'(pg-execute "SELECT 1;") ) )
```
quoted second farg works well
```
'(assert-throws 'pg-db-err NIL
'(pg-trans
(catch 'pg-data-err (pg-execute "SELECT 1/0;"))
(pg-execute "SELECT 1;") ) )
```
unquoted fails with "pg-db-err -- Tag not found"
```
'(assert-throws 'pg-db-err NIL
'(pg-trans
(catch 'pg-data-err (pg-execute "SELECT 1/0;"))
(catch 'pg-db-err (pg-execute "SELECT 1;")) ) )
```
unquoted second farg with (catch) on this specific fun works well
```
'(assert-t
(catch 'pg-db-err # or T
(pg-trans
(catch 'pg-data-err (pg-execute "SELECT 1/0;"))
(pg-execute "SELECT 1;") ) ) )
```
explicit (catch) fails as well.
Probably Im missing something?
Thanks.
Best regards, Nail.
сб, 19 янв. 2019 г. в 16:57, Alexander Burger <[email protected]>:
> On Sat, Jan 19, 2019 at 04:27:53PM +0300, Abel Normand wrote:
> > So I have a question, is there a reason to quote functions used as args
> for
> > functions with manually evaluated arguments? I thought that there is no
> > such reason to quote this sub S-expressions because they are not
> evaluated
> > anyway (due to function declaration like for pg-trans or assert-throws)
>
> You mean FEXPRs, like
>
> (de pg-trans X
> ... )
>
> where 'X' is bound to the unevaluated argument list, right? As this
> function
> later *does* evaluate the args with (mapc eval X), it is indeed not good to
> quote these args, as you *want* them to be evaluated.
>
> If they are quoted, they evaluate to the expression itself, instead of
> being
> executed, and this makes no sense here.
>
> BTW, instead of (mapc eval X) it is better to call (run X) or even
> better (run X 1).
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
>
--
С уважением, Наиль.