freenode/#clasp - IRC Chatlog
Search
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.
17:00:33
Bike
Right now I'm redoing the implementation of the argument parsing code (i.e. the translation of enter-instruction), which naturally is pretty complex
18:44:26
Bike
drmeister: just remembered something- while you're messing with discriminators it might be nice to make *current-function-description* or something available so argument counte rrors can be nicer
18:50:26
drmeister
Do you mean to pass it through to the functions that report the argument count errors? That sounds like a good idea and it's pretty straightforward.
18:53:15
Bike
yeah. right now we use *gv-current-function-name* which i think probably shouldn't even exist
18:56:22
drmeister
Right - we should pass in the pointer to the function-description and the pointer to the constants vector. Those two things will give us everything we need.
18:56:44
drmeister
Ah - we have to solve the problem of setting up the generic function name in the function-description. Right now it is LAMBDA