freenode/#clasp - IRC Chatlog
Search
4:25:18
drmeister
Huh - I just learned you can write the loop as: (loop for iiii fixnum below xxxx))
4:35:00
beach
I prefer using of-type explicitly because it is more, er, explicit, and it works for any type.
4:36:43
beach
Speaking of which, at some point I would like to take advantage of the fact that it is highly unlikely that there will be more than a fixnum number of iterations in a loop.
5:04:07
drmeister
That really strikes me as perverse - it's the easiest thing to do in a C-like language.
5:34:11
drmeister
"Speaking of which, at some point I would like to take advantage of the fact that it is highly unlikely that there will be more than a fixnum number of iterations in a loop." "So if there are numeric loop variables, they are typically fixnums." "Not sure how to do it though."
5:36:51
drmeister
Why is it hard to take advantage that it is highly unlikely that there are more than fixnum number of iterations in a loop.
5:37:23
beach
Because you would have to have the compiler write two versions of the loop, and jump from one to the other in case something happens to become a bignum.
5:37:40
drmeister
Ok, I don't mean to be provocative - it just struck me what you said you didn't know how to do it. I don't see what's difficult about it if you know the bounds are fixnums.
5:39:17
beach
So I want to generate a correct loop, even if there is no FIXNUM declaration, but I still want to take advantage of the fact that it is highly unlikely that the loop will iterate more than a fixnum number of times.
5:41:01
beach
Let's drop it. I am not being clear, and it's too early in the morning for me to do better than that.
5:43:38
drmeister
No problem. I didn't mean to make a deal of it. I always assume that you know what you are talking about and that I don't quite understand - and by asking I might learn something.
5:45:52
beach
I tend to assume that everybody has a goal to make Common Lisp safe, and that is not the case. This goal complicates life for me, but it also makes for interesting research opportunities. Most people would just do the equivalent of what you suggested in C++ and not care if the loop variable overflows.
6:47:34
drmeister
But this... Democrat senate votes 40,858,132 votes (55.4%) . Republican senate votes 31,651,154 votes (42.9%) . Yet the Republicans currently have 51 seats and the Democrates 43. The senate is an extremely undemocratic institution.
12:44:08
kpoeck
Looking at the tests, the loop marco as used in ecl and clasp seem to produce wrong declarations for e.g. (LOOP FOR X FROM 1 to 4.0 COLLECT X)
12:45:29
kpoeck
With some compiler optimisation settings clasp checks the declared type and produces an error
12:53:02
jackdaniel
I'd suspect you've added some extra check, ecl does that for high safety settings
12:53:59
Bicyclidine
ecl and clasp use kind of an older version of the same xerox loop that's in sbcl, i think
12:54:40
Bicyclidine
i've done a little bit of updating, though nothing semantic, and i'm sure ecl has too, tho
12:58:45
jackdaniel
kpoeck: you first need to bootstrap it (implementation uses loop internally afair)
12:59:09
jackdaniel
so you'd need to keep loop which is there now and from that build beach's loop and have this version in cl package
13:14:12
beach
kpoeck: It is complicated with Clasp. Much of the SICL code is not meant to be bootstrapped the way Clasp is bootstrapped. So Clasp can use that stuff, but it still has to have its own version during bootstrapping, and that makes the entire system more complicated.
13:26:52
kpoeck
So I am tempted the try the SICL-Loop to see whether this particular issue is solved there
13:27:39
kpoeck
In parallel I will compare ecl/clasp loop against sbcl/ccl loop, perhaps there is an easy fix
13:30:04
drmeister
I don't anticipate any problems incorporating sicl's loop in clasp - just toss it on the pile of sicl we compile in cclasp.
13:35:19
kpoeck
I'f be interested in the result of (macroexpand '(LOOP FOR X FROM 1 to 4.0 COLLECT X))
13:40:33
drmeister
The stackmaps stuff appears to work fine now on macOS. I haven't tested linux yet.
13:42:51
beach
kpoeck: As I recall, there were a few ANSI tests that were wrong, but I don't remember which ones.
13:48:33
beach
As I recall, I tried to follow the specification very precisely, so SICL LOOP may not pass those tests.
13:50:56
kpoeck
So I will try to report them as issues in the ansi-test repository (advise from jackdaniel)
13:55:39
jackdaniel
kpoeck: you mean that ansi-tests has tests which check implementation to conform with undefined behavior? I'm not sure I follow
13:58:42
jackdaniel
or do you mean, that you assume that undefined behavior should result in some kind of error? because if the latter then it is not a matter of conformance but being strict (implementation is free to define behavior which is undefined in a spec to do something sensible and it is still conforming)
14:42:16
kpoeck
I can easily change this in clasp, but I haven't found a place where the order is specified in the ansi
14:43:58
kpoeck
Should I have overlooked something, than we have to change clasp to follow the specification
14:46:00
pfdietz
(I have a copy of ansi-test here; I assume the test names weren't changed in your version)
14:47:10
kpoeck
this one: https://gitlab.common-lisp.net/kpoeck/ansi-test/blob/feature-clasp-changes/cons/pushnew.lsp#L137
14:47:17
Bike
i thought the standard mandated all the standard macros evaluate left to right, but i don't know a reference
14:48:22
pfdietz
"For each of the ``read-modify-write'' operators in the next figure, and for any additional macros defined by the programmer using define-modify-macro, an exception is made to the normal rule of left-to-right evaluation of arguments. Evaluation of argument forms occurs in left-to-right order, with the exception that for the place argument, the actual read of the ``old value'' from that place happens after all of the argument form
14:48:22
pfdietz
evaluations, and just before a ``new value'' is computed and written back into the place. "
14:53:48
jackdaniel
I have some wip with McCLIM interface for running ansi-tests (so instead of sh you'd run tests against clasp from i.e sbcl)
15:03:40
drmeister
Here's an interesting application of machine learning - autocompletion. https://tabnine.com/
15:05:43
Bike
kpoeck: do you mean the adjoin compiler macro is evaluating things in the wrong order?
15:18:37
beach
Bike: It can happen easily. When I imagined writing compiler macros for the sequence functions, I found out that it is extremely hard to preserve evaluation order.
15:19:17
pfdietz
One thing I don't know if it's specified is what happens if the same keyword argument occurs more than once in a macro form. Is only the first one evaluated, or both?
15:20:23
pfdietz
In keyword arguments to ordinary functions, they are both evaluated, but only the first value is used.
15:21:47
pfdietz
Probably not important though. The semantics for ordinary functions is there so you can override keyword arguments using APPLY.
15:24:14
pfdietz
On the other hand, a COMPILER macro had better preserve the behavior of the function it's replacing.
15:24:46
pfdietz
And the function, if invoked as a function, would evaluate those redundant keyword args.
15:26:32
pfdietz
:test and :test-not is a special case. IIRC it's unspecified what happens if you include both.
15:27:56
pfdietz
"The consequences are unspecified if both a :test and a :test-not argument are supplied in the same call to F. "
15:28:50
beach
Then the compiler macro must arrange for all of them to be evaluated, and in the right order.
15:41:40
beach
So a compiler macro without a &rest parameter for a function that takes keyword parameters is necessarily incorrect.