freenode/#sicl - IRC Chatlog
Search
12:45:24
beach
shka_: That is what I will do for SICL, but implementations such as SBCL actually have a "named function" object.
12:47:04
beach
But that's kind of strange if you do (setf (fdefinition 'hello) (fdefinition 'sort)) and then you call (hello ....) and get an error that mentions SORT.
12:49:56
beach
I still think it is weird to have a name as part of a function, just as I would think it would be weird if I did (defparameter *bla* -1) and have *bla* mentioned whenever I do (aref some-array *bla*).
12:51:14
beach
My tentative plan for SICL is to use the source location as much as possible instead, and assume that the developer is not using a raw command-line interface during development.
12:57:34
beach
Source location is usually going to much more informative than the current error messages are anyway, like for example "NIL is not of type NUMBER"
13:08:53
beach
Bike: I have been thinking about what you said about type inference. Does your suggestion mean that instead of writing (if (consp x) ... ...) I would have to write (if (consp x) (locally (declare (type cons x)) ...) (locally (declare (type (not cons) x)) ...)) to inform the type inferencer about the type of x in each branch?
13:14:46
Bike
obviously that wouldn't be much good. i'm just talking about the ir representation. for example (consp x) is rewritten as (typep x 'cons), and then the compiler special cases (if (typep ...) ...), maybe
13:16:37
beach
I think I would have to look at a more complete description of your suggestion in order to understand it fully.
13:17:40
Bike
it's just that with typeq the paths we can go at this point are "typeq understands the entire implementation type system" or "typeq only works for some things and inserting type checks automatically based on declarations is really annoying", as far as i can figure
13:19:23
beach
I think it would be reasonable to have it understand as much of the type system as is useful for optimization. That would vary from one implementation to the other, of course.
13:21:31
beach
Perhaps "understand" is not the right word here. I think the type inferencer would have to make certain approximations in order to limit the amount of computation it needs to do.
13:22:07
beach
And those approximations should always be correct (of course), but could be more or less precise for different implementations.
13:24:11
beach
In the case of SICL, the most important information would be to identify when an object is a FIXNUM, a CONS, a CHARACTER, a SINGLE-FLOAT, or a STANDARD-OBJECT which are the only possibilities for the tagging scheme.
13:25:42
beach
Then, I need for TYPEQ-INSTRUCTION to turn into FIXNUMP-INSTRUCTION, CONSP-INSTRUCTION, etc. whenever possible.
14:05:18
Bike
yeah, we talked about that before. so then (a) what is done with constant typep in the soruce, and (b) what is done when we want to turn a user type declaration into a type check?
14:06:01
Bike
the way i had things before, typeq worked with any type, so a the could be translated fairly straightforwardly into typeq. but that's not tenable if typeq can only handle certain things.
14:06:38
Bike
also, i'm not sure that limiting to a few fixed classes is really enough for good type inference... like integer ranges are important for fixnum arithmetic
14:07:07
Bike
e.g. if you have a countdown using a nonnegative fixnum, that will exit when it's zero (like for loop repeat), if you only know the input is a fixnum you have to account for a bignum result, but if you know it's a nonnegative fixnum you don't
14:08:54
Bike
for (b) i figured you could annotate every the instruction with implementation-provided check code but that's, like, a pretty complicated thing.
14:09:26
beach
I didn't say that this distinction is good enough. I said it is the most important for SICL.
14:12:47
beach
So if it sees a typeq with (or (ARRAY ...) FUNCALLABLE-STANDARD-OBJECT), it does not have to propagate that precision because it is not useful for optimization purposes.
14:13:13
Bike
you say "of course" but that implicates a lot of questions about implementation specific types and deftype...
14:14:20
beach
Again, you have given it much more thought than I have, so I may not see the problems.
14:15:21
Bike
well, i mentioned it before, but a lot of my concern is with the final part where typeq is turned into typep
14:16:07
Bike
in clasp i wrote something that turns a typeq into hir that checks complex types, and it's just very ugly
14:17:13
beach
Indeed. But I think when TYPEQ is turned into TYPEP, it's because the type inferencer failed to do something about it, so it is something really complicated that a compiler macro would not be able to handle anyway.
14:18:57
Bike
er, i don't understand a compiler macro not being able to handle it... the only time a compiler macro can't do something is for an unknown type
14:19:16
Bike
you gave (or (array ...) funcallable-standard-object) as an example, that's perfectly reduceable
14:20:16
Bike
make the or into two conditions, parse the array type, avoid computing upgraded array element type, avoid a loop over the array dimensions
14:20:48
Bike
possibly reduce the funcallable-standard-object check into a fast discrimination thing
14:24:04
Bike
things like (or whatever null) aren't uncommon though, or usually string is going to be an or type too.
14:25:32
beach
I definitely thought about using subtypep to determine whether a type is equivalent to fixnum, cons, character, single-float, or standard-object.
14:27:06
beach
The only remaining thing is the precedence list, and that is independent of the environment.
14:27:27
Bike
what subtypep do you use? for example, the host and target might have different values of most-positive-fixnum, no?
14:28:16
beach
During bootstrapping I can do something very simple. All my integers are fixnums during bootstrapping for instance.
14:29:32
Bike
well, i mean, you have cleavir written to call subtypep. but if you're loading sicl in sbcl, that'll be sbcl's subtypep, which might handle fixnums differently than sicl will. so probably cleavir needs to have access to sicl subtypep.
14:31:04
Bike
well this in general applies to the situation where the host and target differ here, so to speak
14:31:59
beach
Sure, but then, SICL appears to be the only system that uses a host for bootstrapping.
14:32:00
Bike
i don't really understand the first class environments thing. isn't cleavir just loaded in sbcl at first?
14:34:09
beach
So it depends on whether I run the type inferencer in the host or in a first-class global environment.
14:35:05
beach
But there is nothing preventing us from having the type inferencer use a generic function SUBTYPEP and have the client specialize on that.
14:37:46
beach
Again, I haven't (yet) run into such details because I haven't used type inference yet. I guess I'll understand more of the issues later.
14:38:51
Bike
i don't think my previous solutions were very good, so i want to get it right by putting some thought into it, instead of just putting out fires as they arise like i did
14:40:37
beach
I'll be able to help out at some later point, but I am fully occupied with other stuff right now.