freenode/#sicl - IRC Chatlog
Search
5:36:26
fiddlerwoaroof
I'd be willing to setup a VM on one for something like this, if someone wanted to write the software
7:43:25
Shinmera
fiddlerwoaroof: The problem isn't that there's nobody to host. I can do that too. It's that it would be much better if ELS related stuff remained under the ELS' control (as in didier).
8:20:35
scymtym
beach: do you have an opinion regarding https://github.com/robert-strandh/Eclector/issues/40 ?
8:30:02
beach
It looks to me like you are right. I would also like to see the place in the Common Lisp HyperSpec where it says something different.
8:35:57
splittist
your response certainly seems consistent with "Such situations as '), #<, #), and #<Space> continue to signal errors."
8:39:06
scymtym
i think i will check how SBCL implements its behavior (it skips over "#garbage" in the given example) and reject the issue unless i find something enlightening
8:41:07
scymtym
the person who implemented that behavior in SBCL wasn't sure either: https://github.com/sbcl/sbcl/blob/master/src/code/reader.lisp#L1783
8:48:16
scymtym
there's a twist: the behavior has been there forever but the comment is only three weeks old
8:59:49
splittist
From make-dispatch-macro-character: "Initially, every character in the dispatch table associated with the char has an associated function that signals an error of type reader-error."
9:05:38
scymtym
yes, the strategy, at in SBCL's case, seems to be ignoring the failed dispatch and reading the remainder (i.e. "arbage" in the "#garbage" example) using the current readtable, hoping that it fits the unknown syntax well enough to skip over it
9:54:58
scymtym
that's what i suspected since you said the behavior changed. did you write down (or do you remember) the justification for this change?
9:55:31
jackdaniel
as I said, it must be buries somewhere in the issue tracker, but simply looking for "read" didn't shop up this issue, so I gave up
9:57:19
scymtym
sure, thank you. unless your investigation brings to light something new, i still think signaling an error is more in line with the spec
9:59:43
jackdaniel
https://gitlab.com/embeddable-common-lisp/ecl/commit/07391b9cedac1aee00234f99682cdb10bd4a92dd
10:06:26
scymtym
the example cited in the commit message is #\garbage, not #garbage, i.e. an unknown character name, not an unknown macro sub-character
10:07:05
Shinmera
in general the spec is a bit confusing about the ignoring here, as the reader potentially can't know how much there is to ignore
10:07:55
scymtym
it says the mechanism is binding *READ-SUPPRESS* to true and calling READ. and that in turn is specified a bit more clearly
10:08:03
Shinmera
so signalling an error despite what it says about conditionals in this case seems right to me.
10:09:14
scymtym
jackdaniel: also, i don't know the ECL codebase, but is dispatch_macro_character for macro characters or dispatching sub-characters? i can't tell what the intended change in behavior is since there is no corresponding test
10:12:17
scymtym
Shinmera: yes, that's one of the concerns i mentioned in the issue: if i wanted to implement the skipping behavior, how could i accomplish that? SBCL simply discards a token which is not always enough as your examples demonstrates
10:13:07
jackdaniel
scymtym: I didn't implement this change and I don't know this part by heart, but I *think* it is for characters, not sub-characters
10:15:47
scymtym
jackdaniel: hm, maybe it also handles the sub-character if the macro character is #\#? that could explain the change in behavior. otherwise i'm confused
10:18:33
jackdaniel
I've only glanced and the code and I'm not certain about what I said, we may very well assume I was wrong