freenode/#lisp - IRC Chatlog
Search
17:42:23
phoe
My actual question is - since the spec is either unclear or unsatisfiable, what is the behaviour that we actually want to settle on and "standardize" in ansi-tests or beyond-ansi
17:42:54
jackdaniel
phoe: we can't settle or standarize undefine behavior in ansi-tests because that is *not* standarizedx in ansi
17:43:14
fiddlerwoaroof
Initially, every character in the dispatch table associated with the char has an associated function that signals an error of type reader-error.
17:43:31
phoe
(list #\GARBAGE) is unsatisfiable in general either, even though it is in the (non-normative) characters
17:44:02
phoe
fiddlerwoaroof: if that is the case, then reading an unknown dispatch macro character should signal an error
17:45:09
phoe
Dispatching macro characters continue to parse an infix numerical argument, and invoke the dispatch function.
17:45:29
Bike
it says for example that invalid uses of the dot character are suppressed, but also that ') signals an error.
17:45:59
phoe
> No matter what the value of *read-suppress*, parentheses still continue to delimit and construct lists;
17:46:27
fiddlerwoaroof
So, I guess the question is can the reader handle the resulting READER-ERROR
17:46:59
phoe
but this still doesn't rule out e.g. having spaces in input that could be consumed by the reader macro
17:47:35
Bike
you could for example have a situation where cl-interpol may be used, so you have #?")" in read suppressed text
17:48:57
fiddlerwoaroof
I've had to fix code that does things like that inside read-suppressed code so I could load them
17:49:33
Bike
yeah my basic thought is that ansi tests should probably not test read suppress with unknown reader macros.
17:52:37
fiddlerwoaroof
From my tests, it looks like sbcl and abcl implement some sort of heuristic and ccl, ecl, lw and clisp all signal an error
17:55:19
Bike
so the "heuristic" is, i think, just that #? or whatever is ignored, so it just reads foobar
17:58:52
fiddlerwoaroof
I think given the specification of make-dispatch-macro-character, this should print something: (handler-bind ((reader-error (lambda (c) (print c)))) (read-from-string "#+(or) #?foobar 1"))
18:00:48
Bike
i don't think read suppress isn't allowed to put in a handler or do something equivalent, though
18:05:17
Bike
fun fact: the person who added that test is the same person who patched ecl to not signal an error
18:11:36
jackdaniel
I'm not sure how this is relevant (he might have misread the spec, but testing on other implementations may only tell you that implementation implements one or another strategy)
18:13:22
phoe
back to the topic - #\GARBAGE should be read correctly I think, but #GARBAGE needs not be
18:13:52
jackdaniel
examples are not normative of course, still it is worth something that in the example there is both #\garbage and #ralpha
18:14:50
phoe
it is supposed to behave well under read-suppress, even though no numeric argument is provided to it and ALPHA needs not be valid
18:15:00
pfdietz
Handling of bogus char names is relevant, since different implementations may have different char names.
18:25:17
jackdaniel
the spec talks about skipping a printed representation of an expression (even if syntax is slightly invalid), I think that it is a reasonable to asume that in case of dispatch characters expression has (informally) a recursive definition expression=#e expression, given that all defined dispatch characters work that way
18:26:13
Bike
well sometimes it's a token. like for #\ since I just looked that up, or #* since if it used READ it would drop initial zeroes.
18:31:33
phoe
but this implies another constraint on dispatch reader macros - "whatever your reader macro is capable of consuming, it must also make sense if it was READ as a normal Lisp expression with *READ-SUPPRESS* true"
18:32:15
phoe
so it would be forbidden to write #G1(((( which, even though it would be technically correct under some implementation of #G, would also confuse READ with READ-SUPPRESS
18:35:47
jackdaniel
it says about skipping the next "expression" whatever it means, *even* if it is not valid common lisp. so for things which we can /guess/ that are the next expression we should not signal a condition
18:39:55
jackdaniel
^ doesn't fall in this category, because we'd end suppressed reading after #G1, no?
18:42:31
Bike
if we say that a suppressed read error returns no values, it might still have the ((( in a suppressed context
19:08:16
phoe
also in case of a mismatched open paren we end up with an end-of-file error since there is no matching right paren
19:08:52
Bike
it hits #+(or), so the next thing is read with read suppress. it reads #+(or) 1, but there's no actual object, so it continues and reads 2 with suppression. then the suppression is over, so it reads 3 4 5
19:09:27
Bike
so if #g1 is read and that reading returns no values it could be understood to not yet undo the suppression, analogously.
19:14:02
Bike
anyway i stil think the behavior is undefined and the test shouldn't go either way (i.e., shouldn't mandate an error, and shouldn't mandate no error, so overall shouldn't exist)
19:32:02
fiddlerwoaroof
I don't really know why I keep pushing PRs, only about 80% of them get merged
19:32:26
fiddlerwoaroof
But, I hope someone else running into the same issues finds them and can get the software to work
19:34:03
fiddlerwoaroof
luis: CFFI's static linking support is broken on macOS without this patch https://github.com/cffi/cffi/pull/135/commits/1e43f7b62556fc7059c69a9c6d04c25bc9c2061e
19:35:52
fiddlerwoaroof
Basically, for some reason, macOS ignores a .a file if it's produced with ar
19:35:56
semz
Say I have an array in a CLOS slot. It's possible to perform some actions (e.g. computing a checksum) after changes to the slot by defining (SETF SLOT) accordingly, but is there a straightforward way to do the same whenever we only replace some entries of the array rather than the entire thing?
19:36:46
fiddlerwoaroof
And so, when using static-image-op, the cc invocation to link the SBCL runtime with the FFI libs fails
19:38:21
fiddlerwoaroof
I use this here to deal with osicat-hell, https://github.com/fiddlerwoaroof/daydreamer/blob/master/build.lisp
19:39:27
fiddlerwoaroof
Hmm, I should look into using nix hydra to build this, circle-ci charges for macOS
20:24:17
phoe
one of them is Bike's treating it as undefined, which implies removing the test from ansi-test
20:25:15
phoe
the other is jackdaniel's idea of requiring that stuff that is actually read by reader macros must be readable as Lisp data under *READ-SUPPRESS* which would then make it possible for the reader to omit them completely
20:28:35
phoe
the first one is very easy to implement, the second puts additional logical constraints on portable code that clarify the spec's intention on the matter
20:29:15
phoe
namely, the other assumes that the datum that optionally follows the macro is a readable (under *READ-SUPPRESS*) Lisp expression
20:29:50
phoe
and therefore portable code must only use such data, even though stuff like #G1((( is technically legal Lisp
20:30:36
phoe
or rather, it would mandate that code that uses such unusual reader macro data must NOT be read under *READ-SUPPRESS* which in turn means that reader conditionals cannot be combined with such reader macros
20:31:21
phoe
in other words, code that uses such unusual reader macros must be split into separate files that are loaded conditionally on implementations or in the presence of systems that support those reader macros.
20:31:48
phoe
I think that would be enough to satisfy that constraint - isolate #G1((( into its own file and NEVER mix it with *READ-SUPPRESS*.
21:09:44
jackdaniel
I was saying that you can't require signalling error under such circumstances, then I've mentioned what sounds like the most reasonable implementation
21:10:19
jackdaniel
I tend to agree with what Bike said -- consequences are here undefined *especially* that the paragraph in the spec mentions that it should accept even "invalid syntax"
21:11:16
jackdaniel
so I'm OK with commenting out the test with a brief comment why it is not part of the package (pull requests welcome :)
21:13:33
phoe
If anyone has any objections, please throw them at me or the issue at gitlab.clnet/ansi-test
21:13:40
fiddlerwoaroof
Would it make sense to move this sort of test to a separate "interoperability" set of tests
21:14:19
fiddlerwoaroof
It'd be useful to tabulate these testcases and show how each implementation implements this feature
21:18:08
phoe
jackdaniel: would it make sense to merge test suites for package-local nicknames into beyond-ansi?
4:57:03
tourjin
on windows10, windowsemacs with slime, if i run this it creates output file on c:\users\choij not on d:\home where can I check the settings for default file creation?
4:59:22
no-defun-allowed
Probably where you started your Lisp implementation. You may want merge-pathnames and user-homedir-pathname to ensure you are writing to your home directory.
4:59:49
no-defun-allowed
e.g (with-open-file (stream (merge-pathnames "testfile.txt" (user-homedir-pathname)) ...) ...)
5:00:50
no-defun-allowed
Josh_2: I don't wear glasses surprisingly, but if it ticks you off, I can polish them all day.
5:09:06
tourjin
no-defun-allowed , your tip worked fine . thanks. ck_ your tip shows #P"c:/Users/choij". is it determined by emacs? or by slime? how can I change it permanantly to d:/home?
5:09:41
no-defun-allowed
The CLHS page states "An implementation-dependent pathname, typically in the working directory that was current when Common Lisp was started up."