freenode/#clasp - IRC Chatlog
Search
19:51:39
drmeister
I think they are instanceRef and instanceSet. Virtual functions but fastgf will improve that
20:03:54
Bike
i guess the basic issue is, THE considered as a type check operation has to evaluate a form, do something with /some of/ the values, and then return those same values
20:04:08
Bike
which there's no way to do in CL other than like multiple-value-list, which is not what we want to do
20:31:51
Bike
right now it works by context: types are checked if a fixed number of values are used. i think that's fine. (multiple-value-call foo (the integer x)) won't type check x, but that's quite rare anyway
20:38:05
Bike
to do that with the new stuff, the implementation would basically need to provide a form for each type, that does the test. and a primitive type. like (the integer x) would be a the-ast with types ((or fixnum bignum)), and with asts [result of converting (unless (typep x 'integer) (error 'type-error ...))]
20:39:37
Bike
and then in hir if it was in a values context it would be totally discarded; otherwise it's a THE instruction or whatever that typep compiles into, depending on safety policy
20:44:39
Bike
but if cl type logic is moved up to source level - which makes sense to me - something like that has to happen anywy
20:47:38
Bike
right now they get preserved all the way down to HIR, which is why typeq instructions are converted into typep calls
20:48:33
Shinmera
But you'd still need some form of type information at the lower levels in order to transformations, yeah?
20:48:58
Shinmera
Sorry if I'm asking things that you've already stated before-- I haven't been keeping up with this as much as I'd like
20:49:16
Bike
the (new) idea is there's only "primitive" type information - some set of "simple" types defined by the implementation that it can check easily
20:50:21
Shinmera
From my understanding of information in compiler optimisation I would expect the kind of information to get more complex as you go down the compilation, rather than becoming more simple.
20:51:43
Bike
well, so, inference understands types that are either primitive, or a join (or ...), or a negation of a join
20:53:26
Bike
the idea is that all the primitive types are disjoint, so (and ...) is usually unneeded
20:54:59
Shinmera
Anyway, I'm just thinking in terms of like classes where things like (and foo bar) would make a lot of sense even if there is not necessarily a concrete class that implements exactly this conjunction
20:55:39
Shinmera
Since you could have two classes that share both foo and bar, but have other superclasses as well.
20:57:29
Shinmera
Eg (declare (type (and a b) x)) (typecase x (a ..) (b ..) (c ..)) b and c can be eliminated.
20:58:33
Bike
there's certainly a lot more types that could be dealt with. like... any kind of type theory, for one. but right now i pretty much just want to speed up arithmetic and such
21:00:15
Bike
that should be like, 90% of it really. after that is kind of diminishing returns i think. interesting returns, but still
21:02:29
Shinmera
I don't know. In the absence of something like SBCL's deftransform, not being able to eliminate a lot of typecasing and such is going to be a burden.
21:04:33
Shinmera
I mean, I'm mostly just FUDing here, since I have no real evidence to back up my fears.
21:05:10
Shinmera
I'm just concerned that code might bloat a lot if the inference isn't smart enough and there's no mechanism to do more precise code transformation than compiler macros
21:07:14
Bike
but right now? i mean, i only just fixed it up so that calling map doesn't do a bunch of subtypep calls
22:27:31
Bike
by the time cleavir typeq is changed, every last bug in the primitive typeq will have been found :v
0:36:06
drmeister
I can automatically convert plists to these Python like dicts by converting the symbol keys with (camelize (string-downcase (string key))) where :the-key -> "theKey" (what nglview expects).
0:37:40
drmeister
There's a question about exactly when I convert the plists to dicts - I'd like to do it as late as possible.
0:38:30
drmeister
There are other issues in that these dictionaries get sent back and forth between the kernel and the javascript frontend as JSON dictionaries.
2:51:21
beach
Bike: I need to re-read what you wrote and ask questions about it. But I am still working on my morning coffee.
3:08:18
beach
Bike: To answer one of your questions, it might be OK for now to check only type information that the inferencer uses, but ultimately, there must be a way to make THE mean a real type check for implementations that want that.
3:11:47
beach
Bike: Ideally, simple cases of THE should turn into something the inferencer can use, and complicated cases into run-time type checks. Some cases may turn into a combination of those.
3:12:49
beach
Bike: You write: "the implementation would basically need to provide a form for each type".
3:13:55
beach
Also, since there are an infinite number of types, how would an implementation be able to supply ANYTHING for EACH TYPE?
3:14:50
Bike
okay, so i thought how this was going to go was that typeq would only do primitive checks, and for general lisp types you do (typep foo 'some-type), right? and typep maybe expands into a bunch of typeqs?
3:17:43
beach
I think in general, TYPEP on a constant type may expand to a combination of TYPEQ and more TYPEPs that can not be further simplified.
3:19:42
Bike
i implemented a typep compiler macro to expand into calls of those things. but that's not important.
3:19:50
beach
It is always VERY HARD for me to understand what is said on IRC, so you need to be more explicit when you explain things to me.
3:21:24
beach
It seems reasonable to me that THE would always go through TYPEP, but then, as far as I can tell, every type check could go through TYPEP since it would generate a TYPEQ for simple cases.
3:23:36
Bike
Well the "special" part is that it would have to be in generate-ast or cst->ast. like, the THE converter would built an obvious typep form, and that would have to be converted (to get the expansion in terms of typeq)
3:25:32
beach
Sure. That looks like a very reasonable thing to do for basically any type declaration or type check.
3:26:44
beach
OK, so what is it that has to be in generate-ast or cst-to-ast as opposed to at the source level, and why?
3:27:39
Bike
the way THE is defined, it declares types for some values of a form, and then returns all values of the form. this can't really be done in CL without making all the values concrete somehow, like by multiple-value-list.
3:30:22
Bike
if you have a THE ast, and it's in a values context, it makes a the-values-instruction. if it's in a single value context, it's a the-instruction.
3:31:13
Bike
then thes->typeqs turns the-instructions into typeq-instructions pretty straightforwardly, and the-values-instruction is just deleted. which isn't great, but it does mean that all the most common type declarations are asserted.
3:35:58
Bike
so if i did the same thing but using typep, during generate-ast the typep/error form would have to be compiled and stored in the the-ast, and the equivalent to thes->typeqs would pull it out and use it instead of just typeq instructions like now.
3:40:13
beach
About checking the type of standard instances, it is very tricky because a different thread can do a change-class at any time.
3:41:37
beach
I should definitely put THE on the back burner in my head so that I can give it some thought from time to time when I am otherwise idling.
3:42:55
beach
Bike: It would be very helpful if you could write down all the considerations discussed her, like in the Cleavir documentation, so that we can work on it and turn it into something that I can re-read and that others can understand.
3:43:49
Bike
i wrote a lot for kildall too, by the way. need to format it and stuff before it goes in.
3:44:32
beach
That would also be very helpful. I can understand explicit text like that much better than IRC snippets. And it can be worked on and improved until I understand every detail.