freenode/#lisp - IRC Chatlog
Search
12:31:32
pjb
pfdietz: this is implementation dependent, you could get (1 2 3 4 5). In that case, the variable in the finally may be yet a different binding.
12:41:21
pfdietz
"step v.t., n. 1. v.t. (an iteration variable) to assign the variable a new value at the end of an iteration, in preparation for a new iteration."
12:55:52
phoe
In safe code, must (let ((x 0)) (declare (fixnum 0)) (setq x :zero)) always signal an error? Or are the consequences undefined?
12:56:09
phoe
http://clhs.lisp.se/Body/d_type.htm tells me, 2. During the execution of any setq of the declared variable within the scope of the declaration, the consequences are undefined if the newly assigned value of the declared variable is not of the declared type.
13:08:12
phoe
this implies that (locally (declare (optimize safety)) (let ((x 0)) (declare (fixnum 0)) (setq x :zero))) is safe code
13:11:50
phoe
uh I mean (locally (declare (optimize safety)) (let ((x 0)) (declare (fixnum x)) (setq x :zero) x))
13:15:48
phoe
"the consequences are undefined if the newly assigned value of the declared variable is not of the declared type.
13:18:10
phoe
But clhs 3.3.1 says, "In general, an implementation is free to ignore declaration specifiers except for the declaration, notinline, safety, and special declaration specifiers."
13:18:29
phoe
So if the implementation does not ignore it, then, uhhh. It's implementation-dependent what happens?...
13:20:44
pjb
phoe: what is implementation dependent is how the implementation generates the code. But the semantics of type declarations are rather clear.
13:22:11
pfdietz
The difference between implementation dependent and undefined is that a conforming program may have code with the former behavior, but not the latter
13:22:29
phoe
pjb: I need the standard's words on it. Is the above ALWAYS supposed to generate a runtime error in safe code or not?
13:24:51
phoe
The question therefore is: if we loop from 0 to most-positive-fixnum, is this allowed to be OF-TYPE FIXNUM or not?
13:25:39
phoe
Because if yes, then the variable's value must not be (1+ most-positive-fixnum) in epilogue.
13:26:09
phoe
And if it is (1+ m-p-f) then OF-TYPE FIXNUM is invalid which is contrary to user expectations I think.
13:26:13
pfdietz
Personally, it would be more useful if the var's value in the epilogue is at most the upper bound (for positive stepping)
13:29:29
pfdietz
the IN case is interesting. (loop for x of-type foo in list-of-foos do ….) What happens when the list is empty?
13:29:32
Shinmera
Eg having the last cons in the epilogue for ON stepping allows doing easy modification of the tail without having to do your own stepping.
13:30:17
pfdietz
The wording about initializing the var to a value that is of the type... I don't think I tested for that?
13:30:57
jackdaniel
and more seriously it should do the same thing as for implicit initialization of structures with slots of specified types
13:33:05
pfdietz
"If the optional type-spec argument is supplied for the variable var, but there is no related expression to be evaluated, var is initialized to an appropriate default value for its type. For example, for the types t, number, and float, the default values are nil, 0, and 0.0 respectively. "
13:33:21
pfdietz
(that's for local variable initializations, not iteration variables, but the question remains)
13:35:36
pfdietz
Makes me think there should be a bottom value, which is undefined to compute anything on, or even compare, but that is formally in every type (even NIL).
13:35:43
Shinmera
ACTION muses about defining a predicate that tests for a specific algorithm and using this to have the compiler generate an appropriate program as an appropriate default
13:36:54
jackdaniel
one could argue that if a valid default is not known compiler should signal an error
13:41:38
pfdietz
The practical solution would be to have the OF-TYPE be done with a (LOCALLY …) around the loop body, and another LOCALLY with a declaration of type (OR NULL …) around the epilogue.
13:42:44
phoe
the standard doesn't say anything about setting variables to NIL once the epilogue is reached
13:46:05
phoe
OK - please review this, https://gist.github.com/phoe/335fecfdc195bddd47ab0928b0e62e52
13:48:11
phoe
jackdaniel: and I am not, since I've found a way to invalidate the option where 6 is returned
13:50:24
pfdietz
I keep throwing stuff into my copy of ansi-tests that isn't for public inclusion. I need to refactor.
13:53:06
phoe
If yes, then you could add it to ansi-test but perhaps export it as a separate function or set of functions, and describe those in the README.
13:53:32
pfdietz
It should be, yes, and I've applied it to many implementations. But I feel it's a separate thing.
13:54:37
pfdietz
One new tweak to it, the mutational generator, is pretty sbcl specific. It assumes that if the compiler throws an error, that's a bug. But that's only an sbcl design principle, not something required by the standard.
14:02:01
pfdietz
I am working on a testing thing that will be very sbcl-specific. But it's intended to test test suites, not implementations, so that's ok.
14:11:34
pfdietz
A generalization of that: mutation testing. That is, a way to mutate the source code of some software under test, to confirm that every mutant (that doesn't leave behavior unchanged) is detected by the test suite.
14:12:10
pfdietz
Figuring out if mutants are sterile (do not change behavior) is the central problem, but there are interesting tricks for that.
14:13:07
pfdietz
I was applying a prototype to some of the internal code from SBCL (like, the implementation of APPEND and such) to see if ansi-tests killed all the mutants.
14:19:31
phoe
OK, SBCL/CCL/ECL tickets created. I can't log into the tracker for ABCL just yet and I don't know where to create CLISP bugs.
14:29:56
Bike
clasp copies ecl and none of the few changes i've made to the loop implementation would involve this
14:35:29
jackdaniel
"code is conforming (...) since the user wants to perform an iteration for every fixnum" is hardly a argument for what is conformant (it may be argument for adopting one behavior), I'm sure that there are some mechanisms with undefined consequences with overlap with user "wanting"
14:36:33
phoe
jackdaniel: that's the weakest point of my argument since it literally is up for human interpretation
14:36:46
jackdaniel
my point is that "user intention" is not a universal guide of what is a valid common lisp
14:36:54
phoe
but my question is, if this is not true, then what does (loop from m-n-f to m-p-f ...) mean
14:38:35
jackdaniel
I don't care much of what is returned from the finally clause; I'm just afraid that if CL is implemented from the standard in 20000 years from now by alien archeologiests code depending on this interpretation may not run :)
14:40:18
phoe
jackdaniel: if OF-TYPE declaration is not good enough in that case then why is it allowed there
14:40:26
pjb
Imagine we try to remake dynosaures from DNA, and instead of getting dynosaures, we get toads! Oops, the specifications was buggy, the actual implementation was dynosaures, but the DNA was wrong!…
14:40:35
phoe
we only want the variable I to go between m-n-f and m-p-f since this is exactly what we specify
14:40:53
phoe
and if that is true, then it is obvious that the variable I is of type fixnum, since we do not intend it to be anything else
14:41:09
phoe
if the implementation assigns something out of the permitted type then it is the problem of the implementation
14:43:15
jackdaniel
"kinda makes sense" and "is the least surprising behavior" - again - is a good argument for unifying behavior, but not for declaring code conforming
14:43:46
phoe
if you find better wordings for these, please let me know - I'm more than happy to edit my writeup
14:49:46
jackdaniel
that quotation is incorrect, because it stipulates that I've expressed that opinion while I was answering the question "how this could be better phrased"
14:51:49
phoe
nope, I need external support - someone who would like to proofread this once more, please do
14:56:25
phoe
jackdaniel is correct but I'm too braindead at the moment to integrate his comment into the text.
15:29:39
phoe
I never even imagined that (make-condition '(or foo bar) ...) would be permitted by the spec
15:30:58
phoe
beach: does WSCL take care of cases such as https://gitlab.common-lisp.net/ansi-test/ansi-test/blob/master/conditions/make-condition.lsp ?
15:36:30
Kabriel
phoe: jackdaniel: remember, only you can tell what your program's intent is, not your compiler!
15:37:49
phoe
pfdietz: is there a way to run the tests without the ones noted with these ansi-cl problems?
15:50:32
phoe
huh, if inside CCL I do (load "/tmp/ansi-test/gclload1.lsp") then it tells me that File "compile-and-load.lsp" does not exist.
16:15:20
pfdietz
My original version of this assumed running the tests from the ansi-test directory. There was some churn on the loading code later (LPNs and such).
16:15:43
pfdietz
I did not want to use defsystem (later asdf) because those may not have been available on the lisp under test.
16:22:36
phoe
pjb: that would imply that (deftype foo () 'condition) (make-condition 'foo) should work
16:23:05
phoe
pjb: also if foo and bar have different slots, then what is the type of the thing that you get from the '(or foo bar) thing
16:37:55
jackdaniel
pfdietz: I want to replace makefile-based "start" with another lisp which runs tests against some other implementation(s)
16:38:17
jackdaniel
that would also enable nice result intercepting and reporting even on implementations which do not fully implement cl
16:38:20
phoe
if it encounters "#\G))))" it cannot infer that it should stop reading when it encounters parens; maybe the reader macro just gobbles up five characters whatever they are
16:43:01
phoe
an unknown reader macro can consume an arbitrary number of characters from the reader string before returning, it can read a Malbolge program and execute it
16:43:23
phoe
so when read-suppress encounters an unknown sharpsign macro, I guess it loses in the general case
16:43:37
phoe
the best thing we can do is to assume that a standard Lisp object follows the sharpsign macro I guess
16:49:27
phoe
https://gitlab.common-lisp.net/ansi-test/ansi-test/blob/master/reader/read-suppress.lsp#L72 <- where does it say in the spec that ";; Undefined macro dispatch characters should not signal an error"?
16:57:44
phoe
and it is impossible to win in this case since https://plaster.tymoon.eu/view/1540#1540
17:01:27
phoe
therefore I'd argue that it is impossible to win with an unknown sharpsign macro and the only sensible option is to signal an error
17:25:53
phoe
this constraint is impossible to satisfy - it is easy to confuse the SBCL reader as well even though it tries to work around this
17:31:04
Bike
i think signaling an error with an unknown compiler macro with read suppress would break real code.
17:34:59
jackdaniel
because someone may depend on the specified behavior for a trivial case and he will point at the spec: there, why you don't support this?
17:35:53
fiddlerwoaroof
Bike: I've come across at least one implementation that does signal an error in that situation
17:36:39
phoe
Bike: jackdaniel: what is a sensible default in that case? When one has an unknown reader macro, then literally anything can follow.
17:37:29
Bike
fiddlerwoaroof: i'm thinking of code that's like, conditionalized to use ccl macros or something
17:37:38
jackdaniel
phoe: if someone puts code for which behavior is not defined (like the case you mention), then it is their fault
17:38:27
phoe
jackdaniel: what exactly is doable in the spec in that case? One of my questions was, where in the spec it says that unknown sharpsign macro characters must be supported - and what does it mean to have them "supported"
17:39:03
fiddlerwoaroof
phoe: for most characters, without a reader macro definition, they're just consituent characters
17:39:27
jackdaniel
phoe: a reasonable assumption is that they consume the next sexpression (either atom or a list). of course that will break for many edge cases
17:39:53
phoe
fiddlerwoaroof: jackdaniel: I understand that one. My question is what is defined, is it possible to satisfy it, and what is actually implemented
17:40:18
phoe
because if the spec requires unknown sharpsign characters to be supported, it requires us to solve the halting problem due to reader macros being Turing-complete.
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?