libera/#sicl - IRC Chatlog
Search
14:38:11
yitzi
beach: I commented yesterday (or something) that figured out how to do capture the line+column information for the example that you and Bike were talking about for source code via pprint. I did so by capturing the current object being printed in the stream style object I came up with in trivial-stream-column. I am thinking of changing the name from "style" to something better that indicates that this is okay...
14:39:40
yitzi
Basically, one can pass this "style" (or stream state) to something like a measure-string method to predict the layout width. Since one could put other things in the "style" maybe call it a stream-state or something? If someone has a good name that would be awesome.
15:09:48
Bike
continuing from what i was talking about last night. big reason i'm thinking of this is i've read some of what the racket people have been doing and it's interesting
15:11:03
Bike
one thing is, you can do something like (defun foo (f) (declare (type (function * float) f)) (... (funcall f ...))), and if f returns a non-float, you could get an error message something like "F, which was declared a (function * float), returned [whatever] instead"
15:11:18
Bike
like the error message refers to the actual declaration that was the problem, even though the error is detected later
15:12:31
Bike
that doesn't in itself have much to do with timing, but with good messages it seems less important to signal errors at particular times
15:18:38
beach
But I think the way to go is what I suggested, i.e. rather than altering the semantics (supposing the AREF specification is fixed, or supposing an operator that is already required to signal an error), do the test early, but then make two branches where one ends in (a better) error.
15:24:19
beach
I don't know. But it seems uncontroversial to do it the way I suggest, whereas there might be objections to eliding some operation that look like it ought to be performed even in case of an error situation following it.
15:25:43
Bike
but if it's specified loosely, an implementation can still choose to do it without elision. it wouldn't require implementation changes or anything
15:26:43
beach
That's true. But we don't have a specification at the moment, other than people's "gut feeling".
15:27:56
beach
And I frankly don't see any way that something like this could be specified more loosely. As in, I can give examples like yours, but can't think of any general way of phrasing it.
15:32:57
Bike
what i'm imagining is the page on aref etc say "an error might be signaled", and then elsewhere there's a section explaining where an error can be signaled, sort of like 3.5.1.1.1
15:33:08
Bike
so i don't think people would care much any more than they do about 3.5.1.1.1 or "error terminology"
15:36:10
Bike
oh, i think 3.5.1.1.1 is just about argument count mismatches and stuff, not type problems