&undefined missing from REPL exceptions

Bug #242575 reported by Derick Eddington
2
Affects Status Importance Assigned to Milestone
Ikarus Scheme
Fix Committed
Low
Abdulaziz Ghuloum

Bug Description

Ikarus Scheme version 0.0.3+ (revision 1521, build 2008-06-19)
Copyright (c) 2006-2008 Abdulaziz Ghuloum

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

They're also inconsistent in other ways, as you can see.

Super low priority for me, just noticed it.

Not an issue outside the REPL:

$ cat uses-undefined.ss
(import
  (rnrs) (rnrs eval))
(write (guard (ex [else (simple-conditions ex)])
         (eval 'foo (environment '(rnrs)))))
(newline)
(write (guard (ex [else (simple-conditions ex)])
         foo))
(newline)
$ ikarus --r6rs-script uses-undefined.ss
Unhandled exception:
 Condition components:
   1. &who: foo
   2. &message: "unbound identifier"
   3. &undefined
   4. &source-information:
       file-name: "uses-undefined.ss"
       character: 203
   5. &trace: #<syntax foo [char 203 of uses-undefined.ss]>

Related branches

Changed in ikarus:
importance: Undecided → Low
Revision history for this message
Abdulaziz Ghuloum (aghuloum) 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?

Revision history for this message
Derick Eddington (derick-eddington) wrote : Re: [Bug 242575] Re: &undefined missing from REPL exceptions

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...

Revision history for this message
Abdulaziz Ghuloum (aghuloum) wrote :

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?

Revision history for this message
Derick Eddington (derick-eddington) wrote :

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

Revision history for this message
Abdulaziz Ghuloum (aghuloum) wrote :

fixed in 1560.

Changed in ikarus:
assignee: nobody → aghuloum
status: New → Fix Committed
Changed in ikarus:
milestone: none → 0.0.4
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.