ian bicking

On Dec 5, 2003, at 10:50 PM, (Brian Harvey) <bh@cs.berkeley.edu>.

I just keep track of where the tokenizer is, and use that when I
encounter an error. (If I'm interpreting a list, the tokenizer is
really just a pointer to a position in the list)

This gives the last token from when the error occurred, which works
well, and is generally better than just a line number. It doesn't
require newlines (though whitespace always makes things more readable,
so throwing it away would cause many other problems).

--
Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org


To unsubscribe from this group, send an email to:
LogoForum-unsubscribe@yahoogroups.com
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

daniel ajoy

I'm changing subject again, sorry.

Shouldn't the procedures that are buried be treated
differently with respect to the error messages produced
inside them?

I think that if a procedure is ********ly buried then
the person that buried it doesn't want the "users" of
the buried procedure to see the errors produced inside
them. I think the errors messages should refer only
to the names of buried procedures saying something
like:

this_buried_procedure could not complete execution.

this_buried_procedure failed to finish.

Daniel

bh

Ian Bicking <Use-Author-Address-Header@[127.1]> writes:

In UCBLogo, by the time the error happens, the procedure is in a form that
doesn't look much like what the user typed. (In fact, it looks remarkably
like a Lisp program. :-)

So at every line break in the original program, I have a sort of invisible
instruction that sets the evalautor's memory of the text of the current
line. I agree with you about line numbers. (Although in the old MIT
PDP-11 Logo, procedure bodies had ******** line numbers like BASIC
programs, with a BASIC-style editing mechanism!)

bh

"Daniel Ajoy" <Use-Author-Address-Header@[127.1]> writes:


Doesn't your newsreader let you edit the subject line? :-)

I've had something like this in mind for a long time, but I've never
quite worked out the details.

I think stuffing this into the meaning of BURY may be the wrong thing;
you might bury a procedure for reasons other than making it quasi-
primitive. For example:
? bury [x y z]
? erall
So I lean toward a separate LIBRARY flag.

This is one of the hard parts of the design. Your message isn't
really all that helpful. The quasi-primitive should give its own
messages! The THROW "ERROR capability was designed for that. In fact,
(THROW "ERROR [MY ERROR MESSAGE]) pretends that the error happened in
the caller, at the point where the procedure that called THROW was
itself called.

This is almost the right thing (another reason I don't have to merge
this with the existing meaning of BURY), except for one small wrinkle:
what if the error is thrown from a subprocedure of the quasi-primitive?
*This* is what the LIBRARY flag has to mean: If a THROW ERROR with a
message comes from someone I call, pretend it's my caller, not I, who
caused the error.

I think that if the procedure doesn't check for and properly report
errors, then it doesn't have the right to hide the nature of the error
that happened within itself. If that happens, you can't debug either
the library procedure *or* the caller!

It's on my list....

pavel boytchev

in elica error precision is on per-character basis. i.e. every
expression
keeps its beginning and end positions, so when there is an error in a
multiline command it is easy to pick up the exact command.


To unsubscribe from this group, send an email to:
LogoForum-unsubscribe@yahoogroups.com
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum