freenode/#lisp - IRC Chatlog
Search
23:07:51
phoe
pfdietz: if he wants to explain that to his coworkers then that would be not the first nor the second or third thing he'd speak about
23:20:27
no-defun-allowed
pfdietz: Method combinations are no good if you're working a language without them.
23:33:04
fiddlerwoaroof
pfdietz: yeah, there's a library that implements CLOS-style generic functions for Clojure, but I think that's a bridge too far for now
23:33:25
fiddlerwoaroof
And, method combinations will make people think of AspectJ, which isn't good where I work
3:18:47
Josh_2
I have a slynk server that was working but now whenever I try to connect my emacs just freezes, any ideas?
7:09:26
jackdaniel
so what was the yesterday's conclusion? undefined beahvior, use do or something more sophisticated? :)
7:11:24
jackdaniel
heh, I now see mail from gitlab.cl.net that phoe proposes to disable tests as undefined behavior
7:11:27
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.
7:12:05
ck_
I couldn't attend the debate, is there a short summary of the behavior in question, other than "loop" ?
7:16:27
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
7:17:35
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?
7:18:35
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
7:22:49
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
7:52:56
fiddlerwoaroof
It's always interesting to see how many different interpretations of a specification arise
7:54:38
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
8:29:55
pjb
beach: didn't you argue at els 2016 that MIT loop was bugged on this point? That it should print 5?
8:32:27
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…
8:51:36
beach
pjb: Yes, that sounds plausible, and that's how I implemented it for SICL LOOP, like I said.
10:29:43
phoe
Yesterday I was trying to figure out how to treat the LOOP issue for a long while and it left me kinda exhausted
10:30:00
phoe
I was hopeful that the conclusion of "let's treat it as undefined" would be decent enough
10:31:24
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.
10:43:12
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
10:45:02
White_Flame
its your very own "is the dress white and gold, or blue and black". Congratulations
10:47:32
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.
10:50:54
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
10:51:24
pjb
phoe: 6 for sbcl ccl abcl ecl, which are the implementations I have currently running on macOS.
10:52:19
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.
10:53:12
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…
10:53:45
Shinmera
phoe: how would it know better if the bounds are dynamic (but only static within a user-known range)
10:53:52
pjb
that's basically my point, with respect to type declarations! The implementation knows better!
10:54:23
phoe
Shinmera: the implementation can compute it - from 1 to 10 by 5 can be at most (integer 1 14)
10:55:01
pjb
(loop for i to (foo z)) the implementation can compute the type of (foo z), and know if it's bound or not.
10:55:53
phoe
it could in theory do a dispatch based on the compiled versions of the code it prepared aheat of time
10:56:34
phoe
but then if the user does OF-TYPE but passes values not of that type it's not the problem of the implementation