freenode/#lisp - IRC Chatlog
Search
22:47:40
fiddlerwoaroof
I just hesitate to compare anything to Java because the people I'm talking to like to criticize Java
22:49:43
Shinmera
fiddlerwoaroof: mixins are another important piece that make CLOS so amenable to protocol design.
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.