&undefined missing from REPL exceptions

The two error messages are different on purpose. One is an expand-time (syntactic) error and the other is a run-time error. Is there a reason why they should be the same?

On Mon, 2008-07-07 at 08:31 +0000, Abdulaziz Ghuloum wrote:
> The two error messages are different on purpose. One is an expand-time
> (syntactic) error and the other is a run-time error. Is there a reason
> why they should be the same?

I just thought it would make it consistent because &undefined is an
official condition type for this error, and if the exception includes it
when using eval directly, and the REPL is doing eval, then why should

> (guard (ex [else (simple-conditions ex)])
    foo)
(#[&assertion] #[&who eval] #[&message "unbound variable"] #[&irritants (foo)])
>

be different than

> (guard (ex [else (simple-conditions ex)])
    (eval 'foo (environment '(rnrs))))
(#[&who foo] #[&message "unbound identifier"] #[&undefined] #[&trace
#<syntax foo>])
>

?

But I'm not sure how &undefined could be used other than like in my R6RS
identifiers checker...

On Jul 7, 2008, at 2:19 AM, Derick Eddington wrote:

> I just thought it would make it consistent because &undefined is an
> official condition type for this error,

I agree. Will add &undefined and maybe change the messages to be
consistent, no problem.

> and if the exception includes it when using eval directly, and the
> REPL is doing eval,then why should
>> (guard (ex [else (simple-conditions ex)])
> foo)
> (#[&assertion] #[&who eval] #[&message "unbound variable"] #
> [&irritants (foo)])
>
> be different than
>
>> (guard (ex [else (simple-conditions ex)])
> (eval 'foo (environment '(rnrs))))
> (#[&who foo] #[&message "unbound identifier"] #[&undefined] #[&trace
> #<syntax foo>])
>
> ?

Well, one is a syntax error, and the other is not. Yes, the repl
is going eval, but that eval happens in the interaction environment.

 > (guard (ex [else (simple-conditions ex)])
     (eval 'foo (interaction-environment)))
(#[&assertion] #[&who eval] #[&message "unbound variable"] #
[&irritants (foo)])

 > (guard (ex [else (simple-conditions ex)])
     (eval 'foo (environment '(rnrs))))
(#[&who foo] #[&message "unbound identifier"] #[&undefined] #[&trace
#<syntax foo>])

> But I'm not sure how &undefined could be used other than like in my
> R6RS
> identifiers checker...

Well, your R6RS identifier checker uses (eval 'id (environment bla))
which does have the &undefined condition, so, it should be alright
regardless, no? E.g., you're not using the interaction environment
(non-R6RS) in your checker, right?

BTW, does you checker work for PLT scheme? Last I checked, conditions
raised inside eval where "different" from the conditions that you can
guard against. Or did that change?

On Mon, 2008-07-07 at 12:22 -0700, Abdulaziz Ghuloum wrote:
> Well, one is a syntax error, and the other is not. Yes, the repl
> is going eval, but that eval happens in the interaction environment.
>
> > (guard (ex [else (simple-conditions ex)])
> (eval 'foo (interaction-environment)))
> (#[&assertion] #[&who eval] #[&message "unbound variable"] #
> [&irritants (foo)])
>
> > (guard (ex [else (simple-conditions ex)])
> (eval 'foo (environment '(rnrs))))
> (#[&who foo] #[&message "unbound identifier"] #[&undefined] #[&trace
> #<syntax foo>])

After you said it's intentional, I realized that it's because the REPL
does its special thing about unbound variables. Sorry, I should have
said, "why should one have and the other not have &undefined?". It
makes sense the other ways they are different, including the different
messages.

> > But I'm not sure how &undefined could be used other than like in my
> > R6RS
> > identifiers checker...
>
> Well, your R6RS identifier checker uses (eval 'id (environment bla))
> which does have the &undefined condition, so, it should be alright
> regardless, no? E.g., you're not using the interaction environment
> (non-R6RS) in your checker, right?

Correct. That's what I was alluding to -- that the reason to make the
REPL have &undefined is for OCD about consistency :)

> BTW, does you checker work for PLT scheme? Last I checked, conditions
> raised inside eval where "different" from the conditions that you can
> guard against. Or did that change?

I think in the past that might have been the case, but ever since I
started using PLT for R6RS in March, it's worked. But PLT's exception
system is still not conformant w.r.t. a few other important things:
http://docs.plt-scheme.org/r6rs/conformance.html

fixed in 1560.