freenode/#sbcl - IRC Chatlog
Search
19:07:07
mfiano
Why is it that SBCL will not print any notes with speed=3 when using SVREF on an adjustable vector, but it will with AREF? It's neither a simple-array nor a simple-vector, yet the former is accepted.
19:08:04
mfiano
And on that note, is there a way to optimize access of an adjustable vector of type `(vector some-struct-type)`?
19:09:48
mfiano
There are 2 questions here. The first: (defun foo (a) (declare (optimize speed)) (svref a 42)) is accepted when A is known to not be a simple-vector, even though CLHS says it accepts a simple-vector only.
19:12:09
mfiano
It's not conforming to call svref on a non-simple-vector, so why doesn't SBCL notify me of the mistake, when it deduces that the type is not a simple-vector?
19:20:45
phoe
because then you could defstruct slot :type (and (vector octant) (not simple-array)) which should explicitly rule out simple arrays
19:21:04
phoe
and SVREF should no longer compile cleanly because it clearly does not receive a sv argument
19:23:44
stassats
If make-array is called with one or more of adjustable, fill-pointer, or displaced-to being true, whether the resulting array is a simple array is implementation-dependent.
19:24:04
phoe
"The type of an array that is not displaced to another array (...) is a subtype of type simple-array."
19:25:34
Bike
there's no portable way to specify the type of arrays that are displaced, i don't think
19:25:49
stassats
there's nothing really to optimize about non-simple-arrays, other than provide compile time warnings
19:27:00
phoe
then I assume that an eventual DEFTYPE NON-SIMPLE-ARRAY would need to have #+sbcl in it
19:27:38
Bike
(and array (not simple-array)) could be the bottom type, so it's probably not super useful
19:28:14
phoe
the #-sbcl implementation could use SATISFIES to be really portable at the cost of inefficiency
19:28:32
Bike
there is no way to make an array that is definitely not a simple-array, so you couldn't declare anything to be that type
19:28:54
mfiano
I'll probably just (locally (declare #+sbcl ...) (aref ..)) for this, since it's only accessed in this one location
19:29:39
Bike
yes, so if your code is standard conforming, you couldn't actually use this type for anything. you'd be doing #+sbcl anywhere anyway
19:30:01
Bike
(although realistically no implementation actually has an empty non-simple-array type, though i think it's planned for SICL)
19:40:16
phoe
is there a way to see the expansion of some piece of code post-transformation? like transformexpand-1 or something?
19:49:14
rpg
Another question -- anyone have a pointer to some information source (e.g., blog post) about how to interpret SBCL's compiler notes?
19:49:36
rpg
There's a little in the manual, but only about how to parse out the four(?) components of a note.
19:52:20
phoe
but the transforms themselves *are* written in mostly-Lisp, which is what is giving me hope
19:52:55
Bike
but they operate on IR. they return some lisp code which is then converted into IR and fitted into the rest of the IR.
19:53:26
phoe
if slime-macrostep is capable of working with macrolets, then I assume that such a mechanism would be also possible for transforms
19:53:38
karlosz
it seems to have a bunch of weird oddities like the macroexpansion problem and less debugability. it seems bad that we depend on it for bootstrapping the image now
19:54:26
karlosz
in particular i think it means we can't even build the system on high debug because we can't normally cross compile everything
19:54:36
phoe
I mean, that mechanism could try to compile-and-transform a piece of code, intercept the transform's output, and splice it back in place of the transformed code snippet
19:57:17
karlosz
phoe: what you're saying doesn't seem impossible to implement, but it'd be a lot of work
19:58:28
karlosz
since now we've hamstrung ourselves into depending on stuff being fopcompiled to bootstrap
19:58:52
karlosz
it would be nice to restore being able to use the normal compiler always for bootstrapping the system
20:00:45
karlosz
it would just be cleaner to be able to build without assuming the fopcompiler is on, methinks
20:03:47
karlosz
i still don't understand. isn't there still the issue that we have worse source locations and other debug info during cross compilation?
20:04:15
karlosz
its still applicable, right? since we would potentially want those things for system code
20:05:50
karlosz
i think we still have some toplevelish stuff that gets fopcompiled that warrants better debuggability, but i see your point
20:09:44
karlosz
anyway, i guess i'd be happy with just having one less compiler thingy if the fopcompiler turns out to not give much gain