Bourne has quit [Remote host closed the connection]
random-nick has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 240 seconds]
cartwright has quit [Remote host closed the connection]
__jrjsmrtn__ has quit [Ping timeout: 240 seconds]
__jrjsmrtn__ has joined #lisp
cartwright has joined #lisp
bitmapper has quit [Ping timeout: 265 seconds]
quazimodo has quit [Ping timeout: 268 seconds]
quazimodo has joined #lisp
techquila has joined #lisp
mindthelion has quit [Ping timeout: 240 seconds]
shifty has joined #lisp
mindthelion has joined #lisp
<pjb>
LOOP: make it fast, or make it correct!
techquila has quit [Ping timeout: 240 seconds]
EvW1 has quit [Ping timeout: 276 seconds]
matijja` has quit [Ping timeout: 268 seconds]
semz has quit [Ping timeout: 245 seconds]
Josh_2 has quit [Remote host closed the connection]
Josh_2 has joined #lisp
Josh_2 has quit [Remote host closed the connection]
alca has quit [Quit: bye!]
semz has joined #lisp
hdasch has quit [Ping timeout: 264 seconds]
hdasch has joined #lisp
goofist has quit [Ping timeout: 264 seconds]
sahara3 has joined #lisp
techquila has joined #lisp
<sahara3>
buenas
mindthelion has quit [Ping timeout: 276 seconds]
<ebrasca>
pjb: I am sure you can make fast and correct.
<no-defun-allowed>
"fast and correct" is why we're here.
toorevitimirp has joined #lisp
sahara3 has quit [Ping timeout: 276 seconds]
milanj__ has quit [Quit: This computer has gone to sleep]
impulse has joined #lisp
akoana has joined #lisp
abhixec has joined #lisp
Josh_2 has joined #lisp
<Josh_2>
I have a slynk server that was working but now whenever I try to connect my emacs just freezes, any ideas?
<Josh_2>
It worked initially and now it just freezes each time I try to connect :O
renzhi has joined #lisp
<Josh_2>
OH wait
<Josh_2>
It's one of those things where I was just doing something REALLY stupid
<Josh_2>
xD
vaporatorius has quit [Read error: Connection reset by peer]
karlosz has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
vaporatorius has quit [Read error: Connection reset by peer]
clothespin has joined #lisp
toorevitimirp has quit [Ping timeout: 264 seconds]
gravicappa has joined #lisp
asarch has joined #lisp
asarch has quit [Client Quit]
mathrick has joined #lisp
asarch has joined #lisp
toorevitimirp has joined #lisp
ebrasca has quit [Remote host closed the connection]
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` has joined #lisp
X-Scale` is now known as X-Scale
karlosz has quit [Quit: karlosz]
mathrick has quit [Ping timeout: 250 seconds]
karlosz has joined #lisp
<beach>
Good morning everyone!
igemnace has quit [Quit: WeeChat 2.6]
ggole has joined #lisp
<Josh_2>
Morning beach
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
<LdBeth>
hello
<beach>
Hello LdBeth.
mathrick has joined #lisp
asarch has quit [Quit: Leaving]
enrio has joined #lisp
mathrick has quit [Ping timeout: 240 seconds]
shifty has quit [Ping timeout: 268 seconds]
ArthurStrong has quit [Quit: leaving]
karlosz has quit [Quit: karlosz]
dale has quit [Quit: My computer has gone to sleep]
vlatkoB has joined #lisp
manualcrank has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
dddddd has quit [Remote host closed the connection]
techquila has quit [Read error: Connection reset by peer]
techquila has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
akoana has left #lisp ["Leaving"]
enrio has quit [Ping timeout: 240 seconds]
mikecheck has quit [Remote host closed the connection]
codeasone has joined #lisp
<jackdaniel>
so what was the yesterday's conclusion? undefined beahvior, use do or something more sophisticated? :)
<beach>
I don't think there was a conclusion.
cosimone has joined #lisp
<jackdaniel>
heh, I now see mail from gitlab.cl.net that phoe proposes to disable tests as undefined behavior
<beach>
For WSCL, I am debating whether to explicitly specify that the behavior is undefined or whether to define the behavior. And if the latter, what alternative to opt for.
<ck_>
I couldn't attend the debate, is there a short summary of the behavior in question, other than "loop" ?
<jackdaniel>
ck_: (loop for i from 0 to 5 finally (print x))
<jackdaniel>
shall it print 5 or 6
<beach>
Nice summary.
<jackdaniel>
thank you
<ck_>
I see, thanks
milanj__ has joined #lisp
<jackdaniel>
beach: if it were a vote for a preferred alternative I'd say that "6" is more useful; it makes the mental model of what's going on easier: increment always goes after the iteration and finally goes after all iterations
<aeth>
the other part of the debate iirc was :of-type (integer 0 5)
<aeth>
(loop for i of-type (integer 0 5) from 0 to 5 do (print i)) ; should this give a type-error when 6 is reached even though 6 is only used in terminating the loop?
<beach>
jackdaniel: I was going to say what aeth just said, or something simlar.
<beach>
But I am not going to participate in a new debate all over again.
<jackdaniel>
right, I've left it out because of-type seems to have clear semantics: if we choose to increment x to 6 that should signal a condition, if we choose not to increment to 6 then it will meet criteria
<ck_>
just as I didn't intend to provoke one. Thank you for the summaries though.
<jackdaniel>
(in safe code)
<aeth>
jackdaniel: well, I had to bring it up because if it's unspecified then maybe some implementations would choose both interpretations, i.e. unless the varaible is referred to in a finally (in its final, one above, form) do not have the type-error
<jackdaniel>
good point, thank you for bringing it up
<aeth>
s/varaible/variable/
raghavgururajan has quit [Remote host closed the connection]
rgherdt has joined #lisp
Josh_2 has quit [Ping timeout: 240 seconds]
<fiddlerwoaroof>
I'd be surprised if that didn't print 5
<fiddlerwoaroof>
Anyways, I see I missed the fun :)
<fiddlerwoaroof>
It's always interesting to see how many different interpretations of a specification arise
<beach>
It appears that we will have no choice but to reopen the debate.
<LdBeth>
what about use something like a variable so the user can control the expansion?
<fiddlerwoaroof>
I encounter this semi-regularly at work, where we plan out a project and then, when implementation-time comes around, the team implementing often realize that there still remain at least two interpretations of the plan
<beach>
Yes, this is a know problem and indicates the limitations of the waterfall model.
<fiddlerwoaroof>
We're an "agile" shop and we try to avoid planning as much as possible :)
vaporatorius has joined #lisp
_whitelogger has joined #lisp
<pjb>
beach: didn't you argue at els 2016 that MIT loop was bugged on this point? That it should print 5?
<pjb>
beach: I'd tend to agree with you.
<pjb>
I would note that this is related to C for(unsigned char i=0;i<=MAX_UCHAR;i++), which if not compiled carefully, can be an infinite loop…
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
froggey has quit [Ping timeout: 246 seconds]
froggey has joined #lisp
mabox has joined #lisp
mabox has quit [Remote host closed the connection]
rgherdt has left #lisp ["Leaving"]
<beach>
pjb: Yes, that sounds plausible, and that's how I implemented it for SICL LOOP, like I said.
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
<beach>
pjb: But I am not going to participate in a reopened debate.
quazimodo has quit [Remote host closed the connection]
toorevitimirp has quit [Quit: Konversation terminated!]
toorevitimirp has joined #lisp
quazimodo has joined #lisp
varjagg has joined #lisp
cosimone has quit [Quit: Terminated!]
jonatack has quit [Ping timeout: 276 seconds]
jonatack has joined #lisp
grabarz has joined #lisp
ravenousmoose has joined #lisp
xrash has joined #lisp
milanj__ has quit [Quit: This computer has gone to sleep]
xrash has quit [Read error: Connection reset by peer]
xrash has joined #lisp
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grabarz has joined #lisp
rippa has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
grabarz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phoe>
well shit, this isn't the thing I wanted to wake up to when I went to #lisp
<phoe>
good morning everyone
<no-defun-allowed>
Good morning phoe
toorevitimirp has quit [Ping timeout: 265 seconds]
<beach>
Hello phoe. What are you referring to?
<phoe>
It's kinda amusing
<phoe>
Yesterday I was trying to figure out how to treat the LOOP issue for a long while and it left me kinda exhausted
<phoe>
I was hopeful that the conclusion of "let's treat it as undefined" would be decent enough
<phoe>
Imagine my face when I read the #lisp backlog this morning
<pjb>
phoe: well, since all implementation are not conforming on this point, as a programmer you need to consider it as undefined, until they're all corrected. Ie. do not use the loop variables in the finally clause! But as an implementer, you need to correct it.
<phoe>
pjb: the thing is there's no consensus on whether 5 is the conforming answer
<phoe>
even after reading the sacred ANSI CL scriptures
gravicappa has quit [Ping timeout: 265 seconds]
enrio has joined #lisp
<phoe>
my question is, if it's practically impossible to agree what should the answer be than should we agree on an ANSI-TEST that tests this at all
vaporatorius has quit [Read error: Connection reset by peer]
<White_Flame>
its your very own "is the dress white and gold, or blue and black". Congratulations
<phoe>
:(
<phoe>
all I wanted is for CCL to fail fewer ANSI-TESTs
<phoe>
and look what I've done
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
<pjb>
Perhaps we'd need a comitee of implementers to decide these matters. At least a mail-list. But where all implementers, free and commercial would participate.
vaporatorius has quit [Read error: Connection reset by peer]
<phoe>
did you just say "herding lispers"
<pjb>
phoe: I'm wondering what the commercial implementations do on this?
<pjb>
(on this loop)
<phoe>
if we are down to implementations, is anyone around with a working cl-all? I'd need to see what cl-all says on the issue
<phoe>
pjb: exactly my thought now
<phoe>
run the code on all implementations and see what they return
<phoe>
so far we know that SBCL CCL ECL CLISP ABCL return 6
<pjb>
phoe: 6 for sbcl ccl abcl ecl, which are the implementations I have currently running on macOS.
<pjb>
yes, and clisp.
<pjb>
phoe: now, we may consider that, in a way, the implementation is free to set the loop variable to "anything" it wants in the finally, and that the bug is in the user giving a wrong type.
<phoe>
pjb: that is another issue
<Shinmera>
if that were true the type would always be wrong
<phoe>
whether it is permitted to define the type in FOR-AS
<Shinmera>
because you can't know "anything"
<phoe>
(loop for x of-type foo from a to b)
<phoe>
whether it is permitted for the user to do OF-TYPE in FOR
<pjb>
phoe: I wonder why the implementation don't set it to NIL for finally. for x to 10 finally (return x) could return 20, or 12, if the implementation thinks it's efficient to add more than the by, and to remove some before next loop…
<phoe>
the implementation would know better after all
<Shinmera>
phoe: how would it know better if the bounds are dynamic (but only static within a user-known range)
<pjb>
that's basically my point, with respect to type declarations! The implementation knows better!
<pjb>
Shinmera: it can infer.
<phoe>
Shinmera: the implementation can compute it - from 1 to 10 by 5 can be at most (integer 1 14)
<Shinmera>
phoe: note I said the bounds are /dynamic/
<phoe>
how can they be dynamic
<Shinmera>
uh, you pass a variable for the bounds?
<phoe>
in (from a to b by c) they are only computed once I think
<pjb>
(loop for i to (foo z)) the implementation can compute the type of (foo z), and know if it's bound or not.
<phoe>
or aren't they?
<Shinmera>
phoe: yes, but it doesn't know them at compile-time.
<phoe>
well shit
<phoe>
it could in theory do a dispatch based on the compiled versions of the code it prepared aheat of time
<phoe>
ahead*
<phoe>
but I don't think anyone does that
<phoe>
but then if the user does OF-TYPE but passes values not of that type it's not the problem of the implementation
<Shinmera>
right, so the issue is what does the implementation set it to?
zxcvz has joined #lisp
<Shinmera>
if it can set it to literally whatever, then of-type is entirely useless because you could never pass a type that is correct other than T
abhixec has quit [Remote host closed the connection]
quazimodo has quit [Ping timeout: 246 seconds]
<phoe>
does the specification permit OF-TYPE in FOR-AS clauses?
abhixec has joined #lisp
<phoe>
I guess yes
<pjb>
Yes it does.
<pjb>
for-as-arithmetic::= var [type-spec] for-as-arithmetic-subclause
<pjb>
all occurences of var in the syntax in declaration place are followed by [type-spec].
<phoe>
So what is the user supposed to do in case of (loop for x of-type fixnum from 0 to most-positive-fixnum)
<phoe>
is the implementation allowed to allocate X as fixnum
quazimodo has joined #lisp
<phoe>
or will it try to step it to (1+ most-positive-fixnum)
<phoe>
which might cause havoc in code compiled with safety 0
<phoe>
since the above is theoretically all conforming ANSI CL
<phoe>
so it should work under all circumstances
<phoe>
because if the answer to the original question is 6 then the above code does not allow X to be a fixnum which makes it non-conforming with ANSI CL
<pjb>
phoe: the question is more general: what use does the implementation make of type declarations. If it uses them to effectly allocate low-level memory for untagged/unboxed data, then the secondary question is what happens when you (incf x) to go beyond most-positive-fixnum (or any other internal maximum of the data type used): does it do checks? If yes, then what optimization is that? If the check fails, it has to allocate new mem
<pjb>
store the result or what? Or does it blindly use modulo arithmetic and fail lamentably?
<pjb>
In any case, it sounds very silly to do such a thing (allocate memory for unboxed data).
<pjb>
Ariane-5 etc…
zaquest has joined #lisp
<phoe>
(lambda () (loop for x of-type fixnum from (1- most-positive-fixnum) to most-positive-fixnum do (progn) finally (print x)))
<phoe>
on SBCL with safety 0, this function loops
kajo has quit [Ping timeout: 276 seconds]
<phoe>
on CCL with safety 0, this function loops too
<phoe>
on ECL with safety 0, this function returns most-negative-fixnum
<pjb>
But of course, this is less optimized, since you have a test, a subtraction and an addition, instead of an addition and a test that fails…
<phoe>
on ABCL with safety 0, this function loops
<phoe>
I don't know, am I supposed to open bugtickets on everyone now?
<phoe>
(declaim (optimize (safety 0))) (lambda () (loop for x of-type fixnum from (1- most-positive-fixnum) to most-positive-fixnum do (progn) finally (print x)))
<phoe>
pjb: could you test on clisp?
<pjb>
phoe: yes, they are implementation bugs.
<pjb>
infinite loop.
<pjb>
Oops, sorry. It returns: 1099511627776 = (1+ most-positive-fixnum)
random-nick has joined #lisp
<pjb>
(I forgot to close the parenthesis).
<phoe>
so it doesn't make use of the fixnum declaration
<phoe>
I see
<pjb>
perhaps it does, but it checks.
<phoe>
or this
<pjb>
The thing is that the optimization works 1152921504606846974/1152921504606846975 of the time…
<pjb>
ie. 99.999999999999999913%
<phoe>
I don't understand, do we want to be fast or are we correct
<phoe>
the same optimization works with a similar probability in C
<pjb>
If the implementation can optimize some specific integer ranges (eg. 0..255, or -128..127, or etc), then it can do it, but it needs to be able to determine the type specified by the user, and process the last element of the range specially.
<pjb>
:of-type (integer 0 5) should not pose any problem, since 3 bits can store up to 7. So internally x can be 6, and the user blamed for specifying the wrong type, or the final value be adjusted.
<phoe>
but then finally (print x) accesses X which was declared to be a fixnum
<phoe>
so it cannot be 1+ most-positive-fixnum
<pjb>
:of-type (unsigned-byte 1) :to 255 and similar should be processed specially, for the last iteration.
<pjb>
phoe: yes. Which is why I don't think that x=6 is a good thing for :to. But since x can go way beyond with (loop for x by 3 to 10 finally (return x)) #| --> 12 |# perhaps we should allow final x > max. and the user :of-type is wrong.
<phoe>
how can the user know that the type declaration is incorrect
<phoe>
all they have is the external interface to LOOP
<phoe>
if the implementation needs to make X any type it requires to then it should be impossible to provide OF-TYPE to that variable
<pjb>
the user should know that 0+3k>10 for the last k…
<phoe>
because what if the implementation requires it to be a bignum but the user tells it to be a fixnum
<pjb>
(loop for x of-type (integer 0 12) by 3 to 10 finally (return x))
<phoe>
and also what Shinmera said, what if the bounds are variable
<pjb>
phoe: it may be because the programs runs on a different implementation with a different most-positive-fixnum. Then the implementation must signal the type error.
<pjb>
And if the bound are variable, either you know they're within most-positive-fixnum or you don't. If you don't, don't declare it fixnum…
<phoe>
(loop for x of-type fixnum from (1- most-positive-fixnum) to most-positive-fixnum do (progn) finally (print x)) is theoretically within fixnum
<pjb>
Yep. We're back to the value of x in finally. IMO, it should be most-positive-fixnum.
<pjb>
but what about (loop for x of-type fixnum from (1- most-positive-fixnum) by 3 to most-positive-fixnum do (progn) finally (print x)) ?
<phoe>
in that case it looks like it would have to be (1- most-positive-fixnum) by the same logic
<pjb>
The last iteration is with (1- most-positive-fixnum) so in finally x = (1- most-positive-fixnum) is consistent.
<phoe>
since this is the lowest value that doesn't violate the type constraint
<pjb>
But as you can see, (+ 3 (1- most-positive-fixnum)) is not a fixnum.
<pjb>
So the implementation must not store that into x.
<phoe>
correct
<pjb>
It needs to use a temp variable.
<pjb>
Or to test before computing it.
<pjb>
In both cases, adding the type declarations slows down the progfram.
<phoe>
but it makes no sense from the optimization point of view if the implementation has a temp variable of type integer
<phoe>
since we could just have X as an integer then
<pjb>
But it makes it correct and consistent.
<pjb>
It changes only on the store.
<phoe>
since we do bignum arithmetic anyway then we could drop the fixnum variable altogether and ignore the OF-TYPE
<phoe>
since doing integer + fixnum is slower than doing just integer
Cymew has joined #lisp
<phoe>
or do we just close our eyes and pretend not to notice that we are doing the same shit as C when it comes to edge cases
<pjb>
correctness and consistency!
<phoe>
this means that setting X to 6 in the original question is incorrect in general and all implementations known to me right now are buggy
<phoe>
all I wanted was to fix some ccl ansi-test bugs, and look where I am now
<pjb>
phoe: more specifically, I could not find in clhs the specification of what value should be bound to the loop variables in the finally clause.
<phoe>
pjb: neither could I. The above conclusion comes from the fact that it cannot be safely bound to 1+ most-positive-fixnum if it is declared to be a fixnum and, from the user point of view, it looks like it's a fixnum all the time.
<pjb>
phoe: so we must decide. If we decide on the value of the last iteration, then things are clear. If not, then it will be mostly implementation dependent. (Again, setting it to NIL would be a valid choice. For example, the variables can be bound to NIL before the loop starts…
<pjb>
So, the value of the last iteration is the best choice.
<phoe>
hm
<phoe>
as for the value in FINALLY I think I have found the answer somewhere
<phoe>
the variables are still available in FINALLY since this is the loop epilogue
matijja` has joined #lisp
<phoe>
and setting a variable to NIL is invalid if the user provides OF-TYPE
<phoe>
(loop for x of-type integer ...)
<phoe>
X must not be NIL in that case
<pjb>
phoe: (let (x) (declare (oftype x)) (setf x start) (…)) would be wrong too.
<phoe>
pjb: correct, LOOP implementations don't seem to do that though
<phoe>
(and thank goodness)
varjagg has quit [Quit: ERC (IRC client for Emacs 26.1)]
<phoe>
"A loop macro form expands into a form containing one or more binding forms (that establish bindings of loop variables) and a block and a tagbody (that express a looping control structure). The variables established in loop are bound as if by let or lambda. "
<phoe>
this means that everything inside LOOP (prologue, body, epilogue) is in scope of the bindings
<phoe>
so they have access to the variables
<phoe>
so the epilogue is able to access the variables
<phoe>
I kind of do not believe that this is the end of the argument
<phoe>
it's too easy
<phoe>
there's gotta be a catch somewhere
scymtym has joined #lisp
Necktwi has joined #lisp
<phoe>
if not then I'
<phoe>
then I'll write this down in some sorta blogpost and throw it at the implementations
nowhere_man has joined #lisp
<pfdietz>
That the variables are bound once should be detectable, by use of closures.
<phoe>
What do you mean?
<pfdietz>
(mapcar #'funcall (loop for x from 1 to 5 collect (lambda () x))) ==> (5 5 5 5 5) ;; maybe?
<phoe>
oh, hm
<pfdietz>
As opposed to a separate binding of X for each iteration.
<phoe>
yes, I see
<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.
EvW has joined #lisp
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
toorevitimirp has joined #lisp
<pfdietz>
I think it's clear from the spec that stepping involves assignment, not binding.
<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."
lucasb has joined #lisp
FreeBirdLjj has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
Necktwi has quit [Ping timeout: 268 seconds]
milanj__ has joined #lisp
<phoe>
In safe code, must (let ((x 0)) (declare (fixnum 0)) (setq x :zero)) always signal an error? Or are the consequences undefined?
<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.
toorevitimirp has quit [Ping timeout: 250 seconds]
<phoe>
and this implies undefined behaviour
_paul0 has joined #lisp
<phoe>
I thought that in safe code this mandated a TYPE-ERROR
paul0 has quit [Ping timeout: 252 seconds]
<pfdietz>
No.
<pfdietz>
SBCL interprets declarations as assertions in safe code, but that's not mandated.
<phoe>
so having a DECLARE TYPE in safe code means that, uhh
<phoe>
the code isn't safe? or am I reading this wrong
zcid has joined #lisp
<phoe>
or is this the kind of mistake that safe code is not meant to protect against
<phoe>
(which would be counter-intuitive)
kajo has joined #lisp
stepnem has quit [Ping timeout: 245 seconds]
stepnem has joined #lisp
<phoe>
this implies that (locally (declare (optimize safety)) (let ((x 0)) (declare (fixnum 0)) (setq x :zero))) is safe code
<phoe>
even though it's UB
legit has quit [Quit: WeeChat 2.5]
Necktwi has joined #lisp
wxie has joined #lisp
<phoe>
uh I mean (locally (declare (optimize safety)) (let ((x 0)) (declare (fixnum x)) (setq x :zero) x))
<Shinmera>
Might just be ID, not UB :)
EvW has quit [Ping timeout: 250 seconds]
<phoe>
ID?
<Shinmera>
Implementation Dependent
<phoe>
yes - I am looking for the passage in the standard that says so
<phoe>
I cannot find what happens if a type declaration is violated
<phoe>
other than the UB mention linked above
<phoe>
"the consequences are undefined if the newly assigned value of the declared variable is not of the declared type.
<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."
<phoe>
So type declarations can freely be ignored.
<phoe>
So if the implementation does not ignore it, then, uhhh. It's implementation-dependent what happens?...
<pjb>
phoe: what is implementation dependent is how the implementation generates the code. But the semantics of type declarations are rather clear.
<pfdietz>
The difference between implementation dependent and undefined is that a conforming program may have code with the former behavior, but not the latter
<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?
<phoe>
So... LOOP with OF-TYPE invokes undefined behaviour if the OF-TYPE is incorrect.
niklascarlsson has joined #lisp
<phoe>
The question therefore is: if we loop from 0 to most-positive-fixnum, is this allowed to be OF-TYPE FIXNUM or not?
<pfdietz>
Which gets back to: is the var incremented past the upper bound, or not?
<phoe>
Because if yes, then the variable's value must not be (1+ most-positive-fixnum) in epilogue.
<phoe>
And if it is (1+ m-p-f) then OF-TYPE FIXNUM is invalid which is contrary to user expectations I think.
<pfdietz>
Personally, it would be more useful if the var's value in the epilogue is at most the upper bound (for positive stepping)
<phoe>
Since the user wants literally to (DO-FIXNUMS ...)
<phoe>
or rather DO-ALL-FIXNUMS
Necktwi has quit [Ping timeout: 268 seconds]
Cymew has quit [Quit: Konversation terminated!]
<Shinmera>
I agree with pfdietz, in general.
<Shinmera>
(Even for other cases like ON and IN)
<pfdietz>
the IN case is interesting. (loop for x of-type foo in list-of-foos do ….) What happens when the list is empty?
<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.
<jackdaniel>
clearly x must be 42 then
<pfdietz>
The wording about initializing the var to a value that is of the type... I don't think I tested for that?
<Shinmera>
Good question.
<jackdaniel>
and more seriously it should do the same thing as for implicit initialization of structures with slots of specified types
<jackdaniel>
(imo)
<pjb>
(loop for x in '(1 2 3) finally (return x)) #| --> 3 |# See, last iteration value.
<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. "
<pfdietz>
(that's for local variable initializations, not iteration variables, but the question remains)
<pjb>
What for (integer 33 42) ?
<pfdietz>
(looks up "appropriate" in the glossary)
<Shinmera>
pfdietz: What for (satisfies foo)? :)
<Shinmera>
*pjb
<pjb>
!
<pjb>
:-
<pjb>
)
varjagg has joined #lisp
<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).
* Shinmera
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
krid has joined #lisp
<pfdietz>
(let ((x bottom)) #| you better assign to x before referencing it |# …)
<jackdaniel>
one could argue that if a valid default is not known compiler should signal an error
<jackdaniel>
that "variable must be initialized"
<phoe>
(defclass foo ...) (loop for i of-type foo in x ...)
vaporatorius has quit [Ping timeout: 268 seconds]
<Shinmera>
pfdietz: The void value strikes again
<phoe>
how does the compiler know how to instantiate a proper FOO
<pfdietz>
It cannot, in general.
<jackdaniel>
phoe: in case of standard class instances slot may not be bound
<pfdietz>
(let ((x ⊥)) …)
<jackdaniel>
so there is no problem
<Shinmera>
yeah, standard-classes are no problem.
<jackdaniel>
this question becomes more relevant when you take structure class instances
<pfdietz>
Finally a use for Unicode in symbols.
<phoe>
jackdaniel: let FOO be a protocol class that signals an error on being instantiated
<Shinmera>
of-type bt:thread :)
<Shinmera>
phoe: class prototype.
niklascarlsson is now known as niklas
<phoe>
bt:*current-thread*
<phoe>
Shinmera: oh, that works
<phoe>
but right, structs don't have prototypes though
dddddd has joined #lisp
krid has left #lisp [#lisp]
<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.
<phoe>
why do we want OR NULL there though
<phoe>
the standard doesn't say anything about setting variables to NIL once the epilogue is reached
<jackdaniel>
(loop for i of-type arbitrary-type in () …)
<pfdietz>
To handle the case of zero loop iterations.
<phoe>
I wrote this up like several minutes ago and hope that it is consistent enough
<jackdaniel>
I'm inclined to dub it as undefined behavior and carry along ;_)
<pfdietz>
Looks good to me.
<pfdietz>
There should be a discussion of the issues with the zero iterations case.
<phoe>
jackdaniel: and I am not, since I've found a way to invalidate the option where 6 is returned
<phoe>
pfdietz: this is a separate bug though
<phoe>
maybe you could throw some ansi-tests for that one too
<pfdietz>
I keep throwing stuff into my copy of ansi-tests that isn't for public inclusion. I need to refactor.
clothespin has quit [Ping timeout: 276 seconds]
<phoe>
pfdietz: yes please.
<pfdietz>
Pull the random stuff off into one or more separate repos.
<phoe>
I mean - is the random tester portable CL?
<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.
<pfdietz>
It should be, yes, and I've applied it to many implementations. But I feel it's a separate thing.
<phoe>
OK - I understand. Sounds good.
<phoe>
Anyway - please review the gist I have posted above.
<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.
<phoe>
I see, yes.
matijja` has quit [Ping timeout: 240 seconds]
<phoe>
pfdietz: thanks for the comment. Anyone else before I throw it at implementors?
goofist has joined #lisp
bacterio has joined #lisp
<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.
bacterio has quit [Quit: bacterio]
makomo has joined #lisp
bacterio has joined #lisp
bacterio has joined #lisp
bacterio has quit [Changing host]
<Shinmera>
pfdietz: A coverage system?
<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.
<Shinmera>
oh, nice
kajo has quit [Ping timeout: 276 seconds]
<pfdietz>
Figuring out if mutants are sterile (do not change behavior) is the central problem, but there are interesting tricks for that.
<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.
<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.
<Shinmera>
phoe: ABCL is on github
<Shinmera>
CLISP bugs are on sourceforge
<phoe>
Shinmera: oh! the official page links a trac instance though.
<Shinmera>
the page is outdated, then :)
<phoe>
Shinmera: OK, made an ABCL ticket.
<Shinmera>
phoe: Don't forget Clasp
<Bike>
this still the loop thing?
<phoe>
Bike: take a guess
<Shinmera>
Yes
<phoe>
except I've got kind-of-a-proof that 5 is The Way™
<Bike>
when it says "rpologue" do you mean "epilogue"
<phoe>
Shinmera: do you have a working clasp installation? Does it fail LOOP.1.{39,40}?
<beach>
phoe: So then SICL LOOP is the only correct implementation. :)
<Bike>
er, prologue
<phoe>
Bike: yes, thank you
<Shinmera>
phoe: It copies ECL so
<phoe>
Shinmera: ok, guess so
<Bike>
clasp copies ecl and none of the few changes i've made to the loop implementation would involve this
<Bike>
so go ahead and file it
<jackdaniel>
Bike: if you fix it first, please let me know ,)
<Bike>
"triaged: hard to care"
<Bike>
maybe it's easy to fix though
<phoe>
OK. Six bugtickets created in total. Linked in the gist comments.
<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"
<jackdaniel>
s/with overlap/which overlap/
makomo has quit [Quit: WeeChat 2.4]
<phoe>
jackdaniel: that's the weakest point of my argument since it literally is up for human interpretation
<jackdaniel>
my point is that "user intention" is not a universal guide of what is a valid common lisp
<phoe>
but my question is, if this is not true, then what does (loop from m-n-f to m-p-f ...) mean
<phoe>
yes yes, you are correct
<phoe>
it isn't universal
<phoe>
I just thought (and hope!) that it is good enough for this case
<jackdaniel>
well, from/to is OK, but of-type declaration is not
<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 :)
<jackdaniel>
or, to be precise, may nto run correctly
<jackdaniel>
and as we all know alien archeologists are a group which we care about ,p
<phoe>
jackdaniel: if OF-TYPE declaration is not good enough in that case then why is it allowed there
<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!…
Inline__ has joined #lisp
<phoe>
we only want the variable I to go between m-n-f and m-p-f since this is exactly what we specify
<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
<pjb>
At least, we've got the fossils…
<phoe>
if the implementation assigns something out of the permitted type then it is the problem of the implementation
matijja` has joined #lisp
<phoe>
our intent was clear in that case
<phoe>
`i` is meant to be assigned fixnums only and therefore OF-TYPE makes sense
<phoe>
"hey Lisp, I want the variable I to be of type (integer 1 5)"
<phoe>
"okay, here is I with value 6"
<jackdaniel>
"kinda makes sense" and "is the least surprising behavior" - again - is a good argument for unifying behavior, but not for declaring code conforming
Inline has quit [Ping timeout: 264 seconds]
<phoe>
"what"
<phoe>
jackdaniel: you are correct
<jackdaniel>
conflating these two things is wrong
<phoe>
if you find better wordings for these, please let me know - I'm more than happy to edit my writeup
madand has joined #lisp
<jackdaniel>
I'd say: behavior is undefined, but the least surprising thing to do is
<pjb>
(loop for x in increasing (integer 1 5) collect x) -> (1 2 3 4 5)
<pjb>
(loop for x in increasing (single-float 1.0 5.0) collect x) -> …
<jackdaniel>
hence all implementations should adopt it for the abovementioned reasons
<jackdaniel>
then tests loop.1.39 and loop.1.40 would belong to ansi-beyond test suite ,)
<phoe>
xD
niklas has quit [Remote host closed the connection]
<phoe>
jackdaniel: updated the gist, please let me know what you think.
<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"
<phoe>
OK - let me edit it more
<jackdaniel>
I need to go now ,)
<jackdaniel>
see you
<phoe>
see youu
<phoe>
shit, I am too brain-dead for writing this correctly now
nowhere_man has quit [Ping timeout: 246 seconds]
<phoe>
nope, I need external support - someone who would like to proofread this once more, please do
kajo has joined #lisp
<phoe>
jackdaniel is correct but I'm too braindead at the moment to integrate his comment into the text.
milanj__ is now known as milanj
cartwright has quit [Remote host closed the connection]
khisanth_ has quit [Ping timeout: 276 seconds]
cartwright has joined #lisp
<phoe>
OK - I've edited the last three paragraphs.
FreeBirdLjj has quit [Remote host closed the connection]
freedom has joined #lisp
niklascarlsson has joined #lisp
khisanth_ has joined #lisp
freedom is now known as gnufr33d0m
madand has quit [Remote host closed the connection]
madand has joined #lisp
FreeBirdLjj has joined #lisp
niklascarlsson has quit [Read error: Connection reset by peer]
niklascarlsson has joined #lisp
niklascarlsson has quit [Remote host closed the connection]
<phoe>
pfdietz: oh wow
<phoe>
I never even imagined that (make-condition '(or foo bar) ...) would be permitted by the spec
gravicappa has joined #lisp
<pfdietz>
Corner cases!
<phoe>
even (deftype foo () 'program-error) (make-condition 'foo)
<Bike>
the interpretation that make-condition should allow arbitrary types is just bleh
<Kabriel>
phoe: jackdaniel: remember, only you can tell what your program's intent is, not your compiler!
<phoe>
Bike: I agree
<phoe>
pfdietz: is there a way to run the tests without the ones noted with these ansi-cl problems?
<phoe>
this is too much of a corner case for me
<phoe>
especially since the ambiguity in allowing such a case is absurdly huge
<pfdietz>
(rt:disable-note <note-name>), then (rt:do-tests)
milanj has quit [Quit: This computer has gone to sleep]
<phoe>
I assume that I do something else than loading doit.lisp then, one second
niklas has quit [Remote host closed the connection]
niklascarlsson has joined #lisp
stepnem_ has joined #lisp
niklascarlsson is now known as niklas
manualcrank has joined #lisp
<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.
<phoe>
are pathnames broken or something?
stepnem has quit [Ping timeout: 268 seconds]
wxie has quit [Ping timeout: 250 seconds]
shifty has joined #lisp
<phoe>
It seems they are, I've reproduced that on SBCL and ECL. Ticket time~
matijja` has quit [Remote host closed the connection]
EvW has joined #lisp
<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).
<pfdietz>
I did not want to use defsystem (later asdf) because those may not have been available on the lisp under test.
<pjb>
phoe: as long as (subtypep '(or foo bar) 'condition)
<phoe>
how can the reader know that the reader macro has terminated its reading?
<jackdaniel>
pfdietz: I want to replace makefile-based "start" with another lisp which runs tests against some other implementation(s)
<jackdaniel>
that would also enable nice result intercepting and reporting even on implementations which do not fully implement cl
<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
<jackdaniel>
s/start/doit/
PuercoPope has joined #lisp
matijja` has quit [Ping timeout: 240 seconds]
<phoe>
what should we assume in that case? since it seems unwinnable
<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
<phoe>
so when read-suppress encounters an unknown sharpsign macro, I guess it loses in the general case
<phoe>
the best thing we can do is to assume that a standard Lisp object follows the sharpsign macro I guess
matijja` has quit [Remote host closed the connection]
<Bike>
i think signaling an error with an unknown compiler macro with read suppress would break real code.
orivej has quit [Ping timeout: 240 seconds]
matijja` has joined #lisp
<jackdaniel>
you can't declare non-conformance based on undefined behavior for an edge case
<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?
<fiddlerwoaroof>
Bike: I've come across at least one implementation that does signal an error in that situation
<phoe>
Bike: jackdaniel: what is a sensible default in that case? When one has an unknown reader macro, then literally anything can follow.
<Bike>
yeah, but usually it's something readable
<fiddlerwoaroof>
Lispworks, at least, signals an error on this: #+(or)(a #[ 1 2 3 ])
<Bike>
fiddlerwoaroof: i'm thinking of code that's like, conditionalized to use ccl macros or something
<jackdaniel>
phoe: if someone puts code for which behavior is not defined (like the case you mention), then it is their fault
<jackdaniel>
lisp implementation must support whatever is doable within the spec
<fiddlerwoaroof>
Bike: I think that has to be in a separate file to work
<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"
<fiddlerwoaroof>
this throws on ccl: #+(or)(a #/aaa)
<fiddlerwoaroof>
phoe: for most characters, without a reader macro definition, they're just consituent characters
milanj has joined #lisp
<fiddlerwoaroof>
So, as long as the surrounding parens are balanced correctly #+/#- works ok
<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
<phoe>
fiddlerwoaroof: jackdaniel: I understand that one. My question is what is defined, is it possible to satisfy it, and what is actually implemented
<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.
<phoe>
and being capable of consuming an arbitrary number of chars from the stream.
<fiddlerwoaroof>
O, we're specifically talking about sharpsign macros, sorry
<Bike>
i think what is actually implemented in sbcl is that it just keeps READing stuff.
<Bike>
so (a #&(a b c) d) is fine, but (a #&) d) is an error.
<jackdaniel>
^
<Bike>
...uh, actually that's not an error. i thought it was
cosimone has joined #lisp
nowhereman has joined #lisp
nowhere_man has quit [Ping timeout: 246 seconds]
<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
<Bike>
(a #&( d) signals EOF, but (a #&) d) reads up to the first closing paren.
<phoe>
and I understand that this is a tough question
cosimone has quit [Client Quit]
<jackdaniel>
phoe: we can't settle or standarize undefine behavior in ansi-tests because that is *not* standarizedx in ansi
<jackdaniel>
so it is by definition "beyond" ;-)
<fiddlerwoaroof>
Initially, every character in the dispatch table associated with the char has an associated function that signals an error of type reader-error.
raghavgururajan has quit [Read error: Connection reset by peer]
EvW has quit [Ping timeout: 245 seconds]
<Bike>
so the "heuristic" is, i think, just that #? or whatever is ignored, so it just reads foobar
<Bike>
which is why it has the behavior it does when parentheses are involved.
<fiddlerwoaroof>
I think this is technically non-conforming
<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"))
<Bike>
well, make dispatch macro character isn't necessarily used for #, is it?
<fiddlerwoaroof>
But, since sbcl never signals the condition, it won't ever be handled
<Bike>
oh, but i think it works the same with a new dispatch macro character, so never mind
<Bike>
i don't think read suppress isn't allowed to put in a handler or do something equivalent, though
<phoe>
that is more or less what I am supposed to answer
<phoe>
does test READ-SUPPRESS.17 make sense in ANSI-TEST
cosimone has quit [Quit: Quit.]
cosimone has joined #lisp
<Bike>
i don't think the behavior is well defined. so no.
<Bike>
fun fact: the person who added that test is the same person who patched ecl to not signal an error
<fiddlerwoaroof>
Eventually there won't be any test cases in ANSI-TEST
<fiddlerwoaroof>
:)
<Bike>
they seem to have misread the example in the read-suppress page
<Bike>
it says #\GARBAGE, not #GARBAGE
<phoe>
these are the same though, aren't they
<Bike>
of course not. #\ is a defined reader macro, #g is not
<fiddlerwoaroof>
#\garbage is a character literal
<phoe>
...wait a second
<phoe>
fuck
<phoe>
you are correct
<phoe>
this is an unknown character literal
<fiddlerwoaroof>
And the set of character names is undefined :)
<Bike>
also examples aren't normative anyway ha ha ha.
<phoe>
this invokes #\# #\G
<pfdietz>
read-suppress.17 wasn't mine, was it? I think I stopped at read-suppress.16
<Bike>
it was added by Marius Gerbershagen
<Bike>
i don't know who that is.
<pfdietz>
Some young whippersnapper, no doubt. Kids these days...
<Bike>
except that, like i mentioned, they also changed the relevant ecl behavior.
<jackdaniel>
Marius fixed issue which I have linked above, someone else reported it
<Bike>
yes.
<jackdaniel>
and after fixing it he added the test
<phoe>
did he test on other implementations
<phoe>
I kinda doubt
<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)
<phoe>
well, right
<phoe>
disregard that one
<jackdaniel>
also that remark was kinda condescending
<jackdaniel>
but whatever
<Bike>
mine? i didn't mean it that way
<phoe>
yes it was - sorry about that
<jackdaniel>
phoe's
<Bike>
o
<phoe>
I should watch my tongue
<phoe>
back to the topic - #\GARBAGE should be read correctly I think, but #GARBAGE needs not be
<jackdaniel>
examples are not normative of course, still it is worth something that in the example there is both #\garbage and #ralpha
<phoe>
read-suppress.sharp-slash.1 tests against "#\\boguscharname"
<phoe>
#R is defined though, it's the radix one
<jackdaniel>
right
<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
<pfdietz>
Handling of bogus char names is relevant, since different implementations may have different char names.
<phoe>
s/valid/a valid number in the provided base/
<phoe>
pfdietz: yes, and that is tested
<phoe>
the issue is #GARBAGE which is undefined reader macro #G
<phoe>
s/reader/dispatch reader/
nowhereman has quit [Ping timeout: 268 seconds]
nowhereman has joined #lisp
<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
<jackdaniel>
assume*
<jackdaniel>
in case of undefined dispatch characters*
<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.
kajo has quit [Ping timeout: 276 seconds]
nowhereman has quit [Ping timeout: 240 seconds]
<jackdaniel>
well, there are also strings and other "objects"
raghavgururajan has joined #lisp
<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"
<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
<phoe>
or #G1"
<Bike>
or a user equivalent of #|.
<phoe>
yep
<phoe>
the spec doesn't say anything like that though, or at least anything I remember
<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
<jackdaniel>
#+(or)#g1((( would leave "(((" to be read in my understanding
<phoe>
hmmm
<phoe>
this does make sense
<phoe>
and this directly implies that the limitation I have written above is in effect
<phoe>
otherwise *READ-SUPPRESS* is broken for all reader macros that do not comply with it
<phoe>
such as #G1(((
sjl has quit [Quit: WeeChat 2.2-dev]
<jackdaniel>
^ doesn't fall in this category, because we'd end suppressed reading after #G1, no?
<jackdaniel>
and the next read would start with a character "("
<jackdaniel>
I need to go to the grocery, tomorrow shops are closed, cu o/
<Bike>
if we say that a suppressed read error returns no values, it might still have the ((( in a suppressed context
ebrasca has quit [Remote host closed the connection]
emaczen has quit [Remote host closed the connection]
hiroaki has quit [Ping timeout: 268 seconds]
dented42 has joined #lisp
sshirokov has quit [Ping timeout: 244 seconds]
<phoe>
Bike: I don't understand the example
karstensrage has quit [Ping timeout: 244 seconds]
<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
EvW has joined #lisp
dented42 has quit [Ping timeout: 240 seconds]
<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
<Bike>
so if #g1 is read and that reading returns no values it could be understood to not yet undo the suppression, analogously.
justinmcp has quit [Ping timeout: 246 seconds]
dented42 has joined #lisp
sshirokov has joined #lisp
ljavorsk has joined #lisp
<phoe>
I see
buffergn0me has quit [Ping timeout: 264 seconds]
Necktwi has joined #lisp
<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)
justinmcp has joined #lisp
<phoe>
at this moment I agree with this conclusion
Guest44780 has joined #lisp
buffergn0me has joined #lisp
* fiddlerwoaroof
just discovered the magit forge package
<fiddlerwoaroof>
It's great not having to use the Github website for PRs and Issues
chip2n has quit [Ping timeout: 250 seconds]
cosimone has quit [Quit: Quit.]
Necktwi has quit [Remote host closed the connection]
stepnem_ has quit [Ping timeout: 268 seconds]
FreeBirdLjj has joined #lisp
<luis>
fiddlerwoaroof: I wish it supported Gerrit as well.
<fiddlerwoaroof>
I don't really know why I keep pushing PRs, only about 80% of them get merged
<fiddlerwoaroof>
But, I hope someone else running into the same issues finds them and can get the software to work
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FreeBirdLjj has quit [Ping timeout: 264 seconds]
<phoe>
fiddlerwoaroof: which macOS? all versions?
<fiddlerwoaroof>
The last I tried was high sierra
<fiddlerwoaroof>
The linked stackoverflow issue has the details
Inline__ has quit [Quit: Leaving]
<fiddlerwoaroof>
Basically, for some reason, macOS ignores a .a file if it's produced with ar
<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?
<phoe>
some entries of the array?
<fiddlerwoaroof>
And so, when using static-image-op, the cc invocation to link the SBCL runtime with the FFI libs fails
<phoe>
at this point you no longer access the CLOS object but rather SETF AREF the array
<phoe>
you'll want to write custom method(s) for that I guess
<fiddlerwoaroof>
But I have to remember to use my version of CFFI
<fiddlerwoaroof>
Hmm, I should look into using nix hydra to build this, circle-ci charges for macOS
kajo has joined #lisp
ggole has quit [Quit: Leaving]
bbuccianti has left #lisp ["WeeChat 2.5"]
enrio has quit [Quit: Leaving]
stepnem has joined #lisp
buffergn0me has quit [Ping timeout: 264 seconds]
random-nick has quit [Ping timeout: 268 seconds]
gnufr33d0m has quit [Quit: gnufr33d0m]
ljavorsk has quit [Ping timeout: 268 seconds]
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bitmapper has joined #lisp
buffergn0me has joined #lisp
dented42 has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
vlatkoB has quit [Remote host closed the connection]
gareppa has joined #lisp
<phoe>
so it seems that we have two options regarding the #GARBAGE syntax
matijja` has quit [Remote host closed the connection]
<phoe>
one of them is Bike's treating it as undefined, which implies removing the test from ansi-test
<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
<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
<phoe>
namely, the other assumes that the datum that optionally follows the macro is a readable (under *READ-SUPPRESS*) Lisp expression
<phoe>
and therefore portable code must only use such data, even though stuff like #G1((( is technically legal Lisp
<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
<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.
nullman has joined #lisp
<phoe>
I think that would be enough to satisfy that constraint - isolate #G1((( into its own file and NEVER mix it with *READ-SUPPRESS*.
<phoe>
Does this sound somewhat sane?
matijja` has joined #lisp
cosimone has joined #lisp
Duuqnd has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
<phoe>
jackdaniel: is this what you intended?
abhixec has quit [Ping timeout: 240 seconds]
abhixec has joined #lisp
gravicappa has quit [Ping timeout: 265 seconds]
clothespin has joined #lisp
random-nick has joined #lisp
<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
<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"
<jackdaniel>
(i.e with Lisp dialects which are not Common Lisp)
raghavgururajan has quit [Read error: Connection reset by peer]
Jeanne-Kamikaze has joined #lisp
gareppa has quit [Quit: Leaving]
<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 :)
<jackdaniel>
phoe: ^
<phoe>
jackdaniel: thanks. I'll prepare the PR later today or tomorrow.
<phoe>
If anyone has any objections, please throw them at me or the issue at gitlab.clnet/ansi-test
<fiddlerwoaroof>
Would it make sense to move this sort of test to a separate "interoperability" set of tests
<fiddlerwoaroof>
It'd be useful to tabulate these testcases and show how each implementation implements this feature
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phoe>
fiddlerwoaroof: it would make sense to do that, yes
<phoe>
one such place is called beyond-ansi and is a folder in the ansi-test repository
<phoe>
actually
chip2n has joined #lisp
<phoe>
jackdaniel: would it make sense to merge test suites for package-local nicknames into beyond-ansi?
<phoe>
s/suites/suite/
<phoe>
if yes, I will prepare a PR
buffergn0me has quit [Ping timeout: 250 seconds]
stepnem has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
buffergn0me has joined #lisp
xrash has quit [Ping timeout: 268 seconds]
dented42 has joined #lisp
stepnem has joined #lisp
PuercoPope has quit [Remote host closed the connection]
clothespin has quit [Ping timeout: 268 seconds]
raghavgururajan has joined #lisp
<jackdaniel>
please do
brettgilio has joined #lisp
brettgilio has quit [Ping timeout: 245 seconds]
clothespin has joined #lisp
brettgilio has joined #lisp
raghavgururajan has quit [Read error: Connection reset by peer]
brettgilio has quit [Read error: Connection reset by peer]
cosimone has quit [Quit: Quit.]
brettgilio has joined #lisp
stepnem has quit [Ping timeout: 240 seconds]
brettgilio has quit [Client Quit]
dented42 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
buffergn0me has quit [Ping timeout: 250 seconds]
raghavgururajan has joined #lisp
abhixec has quit [Ping timeout: 276 seconds]
abhixec has joined #lisp
orivej has joined #lisp
cosimone has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]
anewuser has quit [Quit: anewuser]
buffergn0me has joined #lisp
<phoe>
OK - will do that tomorrow
<phoe>
one PR for #GARBAGE, the other for PLN tests
jfb4_ has left #lisp ["ERC (IRC client for Emacs 26.3)"]