freenode/#lisp - IRC Chatlog
Search
19:31:33
beach
note to self, specify the behavior of the for-as-arithmetic subclause behavior better in WSCL.
19:39:55
Posterdati
Posterdati: the c-toolchain code cannot get the value for $CC resulting in using cc which is NOT gcc
20:01:01
Kabriel
The range is exclusive if form3 increases or decreases var to the value of form2 without reaching that value; the loop keywords below and above provide exclusive limits. An inclusive limit allows var to attain the value of form2; to, downto, and upto provide inclusive limits.
20:02:03
Kabriel
but I think most implementations do it wrong; see https://youtu.be/ZJr81DtSwUc?t=204
20:06:11
Kabriel
I think test 1.40 is very similar, except it is testing the inclusive ranges (to, downto, upto, etc), where the value of var should take on the value of form2.
20:06:39
Kabriel
In SBCL it exceeds it, and I suspect this is the case in most implementations using a derivative of the MIT loop.
20:16:03
White_Flame
yeah, that's part of the conflicting part. Does that talk about the value of the variable visible within the body?
20:16:26
White_Flame
or does that constraint extend out to the full lifecycle of the epilogue and such?
20:17:40
White_Flame
and teh sentence before that one is also a very ambiguous one "That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2."
20:18:32
White_Flame
especially if you take the inclusive forms, that sentence makes no sense regarding the intent
20:25:52
White_Flame
it also doesn't help that "iteration" doesn't seem to be explicitly defined, specifically with regards to the fenceposting of "iteration continues until"
20:30:31
Kabriel
White_Flame: I see your point that it is ambiguous. I tend to think of "iteration" as the body (i.e. execution clauses). I would like to say that the epilogue should be included in that, too, but the terms aren't defined.
20:31:38
White_Flame
my main point derives from a bottom-up reading of the mechanics and stepping, which would imply overshoot. The top-down statements like this might be taken to imply no overshoot.
20:43:07
Kabriel
White_Flame: I definitely agree from a mechanics standpoint; the test would always be done after the stepping of var, so the last value of var will not satisfy the test (i.e. in the epiloge). To do otherwise requires extra stuff.
20:44:21
Kabriel
I was thinking about this last week, which is how I stumbled on beach's ELS presentation.
20:44:34
White_Flame
the glossary entry for step as well: "to assign the variable a new value at the end of an iteration, in preparation for a new iteration."
20:44:50
pfdietz
I have no strong emotional attachment to these tests. I've conditionalized tests for lesser reason.
20:45:45
White_Flame
(which again begs what an "iteration" even means in that context. One time around the LOOP body? One pass through that clause?)
20:45:49
pfdietz
At the end of the day, it's up to the implementers to make their decisions. They should, I think, document how they interpret this part of the standard.
20:45:55
Kabriel
Me either. I am interested to hear what beach has to say, since he implemented sicl loop facility differently.
20:47:33
phoe
even if consistency means that we all agree for this to be undefined and therefore impossible to depend on
20:49:12
aeth
All of this talk of iteration makes me wonder why CL hasn't added iterators as an extension yet... or has it? Is that part of that extensible sequences thing that no one uses?
20:49:54
aeth
In particular, though, it seems like it would be useful for using the implementation's sort algorithm
20:50:20
dlowe
one of my someday-maybe projects has always been to make an SERIES implementation that actually integrates gracefully into sbcl
20:51:40
pfdietz
I know some people who prefer it to LOOP. I'm annoyed it breaks Waters' COVER package, but that's mostly COVER's fault.
20:53:18
aeth
pfdietz: I want to like ITERATE, but it's not LOOP-compatible enough so I'm going to eventually write a DO-LOOP that at its base is basically just LOOP with parentheses added around the clauses and keywords required (rather than accepting any symbol package)
20:55:37
aeth
pfdietz: Does ITERATE support sorting? #'sort is pretty weak. It doesn't even accept start and end points.
21:00:22
aeth
pfdietz: An iteration macro could support sorting in a range, at least on vectors, perhaps even composing with the other functionality to determine the start and end range instead of having to know the indices in advance... and combined with iterators, it would be able to sort arbitrary things, not just the built in (whole) sequences that #'sort does.
21:00:37
aeth
Slightly unrelated to pure iteration, but they usually do have things like sum, anyway.
21:01:55
pfdietz
That doesn't really seem to be what ITERATE is about. I suppose merging of two generators could be an interesting capability.
21:02:45
aeth
Well, maybe I am looking at it differently, but to me it seems like the natural extension in functionality past things like summation.
21:04:01
aeth
Possibly. Perhaps the correct way to look at things is (1) providing the primitives for vector and list (and arbitrary iterator) sort and (2) providing the extensibility so that it can be added in
21:04:44
pfdietz
Like making a header cons cell with tail pointer for RPLACD accumulation of a list, and returning the actual head at the end.
21:05:53
phoe
pfdietz: should we comment out those LOOP tests with the rationale that the spec is contradictory and the behaviour is undefined, then?
21:06:12
phoe
I'd suggest commenting them out, because someone in the future might notice this and reignite the religious dispute
21:14:36
pfdietz
When a test is defined, notes can be attached. The function RT:DISABLE-NOTE allows tests with that note to be disabled and not run by RT:DO-TESTS
21:21:13
phoe
https://gitlab.common-lisp.net/ansi-test/ansi-test/commits/master lists some recent activity
21:21:39
no-defun-allowed
Just a little exclamation of disbelief: does GitHub seriously not notify you when someone creates an issue or PR?
21:22:22
no-defun-allowed
I pinged the maintainer (wrote @foo) and they merged my changes to heroku-buildpack-cl.
21:23:17
phoe
check your notification settings and spam folders and whether you didn't un-watch the issue after making it
21:23:50
no-defun-allowed
All on their end. I think I disabled emails for everything, but I should still get it in GitHub.
21:24:54
no-defun-allowed
There's individual check boxes for "email" and "web" notifications. Weird.
21:30:04
sjl
pfdietz: aeth: thanks for nerd-sniping me http://paste.stevelosh.com/041a96442fa3f41de3b78f1b15a2d6c90cb59c92
21:30:16
no-defun-allowed
ACTION figured, but seems odd to allow configuring both rather than, say, choosing both/web only/none
21:47:16
sjl
seems odd that pileup doesn't have heap-vector and heap-list or something like them built in
22:04:07
fiddlerwoaroof
Has anyone written up an introduction to designing protocols as collections of interacting generic functions?
22:17:18
phoe
it is somewhat short on description and theoretical but perhaps could be of use to you
22:20:00
fiddlerwoaroof
I'm trying to find resources to show my coworkers how to design programs using multimethods
22:20:32
fiddlerwoaroof
We're using Clojure, but I've found that a lot of these CL resources are really helpful when writing Clojure
22:20:56
phoe
2) find all prerequisite objects that are needed to properly frobnicate - e.g. foo, bar, and baz
22:21:26
phoe
3) (defgeneric frobnicate (foo bar baz ...)) where ... is any optional/keyword parameters and data that the function will/may need
22:22:43
phoe
you could use existing materials for system level design, except that many design patterns go out of the window since Lisp has better ways of solving those
22:22:56
phoe
and a lot of design patterns were made to work around foo.bar(baz) style of method calling
22:23:19
fiddlerwoaroof
Yeah, but I think what Lisp does have is this concept of defining your system in terms of a set of generic functions
22:23:20
phoe
https://norvig.com/design-patterns/design-patterns.pdf is one resource for exactly this - it describes some patterns that CLOS renders obsolete and/or modifies in a significant way
22:23:54
fiddlerwoaroof
So that, for example, you can specialize the functions one way for testing and then another way for produciton
22:24:31
phoe
protocol classes must be instantiated and protocol functions are GFs whose methods may specialize on concrete classes
22:37:45
fiddlerwoaroof
Yeah, and ultimately results in ungainly system design because of Java's type system
22:41:55
phoe
but Java being a pile of #<unreadable object> isn't the topic here - was just trying to make an analogy
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