freenode/#clasp - IRC Chatlog
Search
3:24:00
beach
It is still very early in the morning here, so I may not be very coherent, but I think TYPEQ is meant for the type inferencer, so there is no need for it to handle arbitrary types; only the ones that the type inferencer can deal with.
3:25:34
Bike
okay, say you have (declare (type B var)), where B is a strict supertype of A, which is an inferencer type. and it's safe code. how's that compiled?
3:25:38
beach
Nobody says that a call to TYPEP with a constant type argument or a declaration should turn into a TYPEQ with the same type given.
3:27:01
Bike
i mean, the basic issue is that typeq is for the inferencer, but it also has actual semantics
3:33:03
Bike
say A is fixnum and B is integer = (or fixnum bignum). typep will redundantly test fixnum, unless it expands into typeq(s) itself
3:35:32
Bike
because then the inferencer would have one join/meet set of operations, and then there'd have to be another one at generate-ast level subtracting things out of full common lisp types
3:37:49
beach
It seems to me the alternative, if you want to do things once only, is to avoid type inference and have everything done by TYPEP.
3:40:54
Bike
right now i'm moving forward as if typeq can handle anything, and in the near future generate-ast will convert typeq's type specifier into an environment-independent implementation-defined type object. then probably some phase in hir but before type inference breaks typeqs apart into usable pieces, and then the inferencer simplifies further into inference types.
3:42:10
Bike
but i'm only just getting to the point of avoiding full typep calls anyway, so i'm just thinking ahead and worrying'
3:43:15
beach
I can't parse the phrase starting with "then probably...". But it is probably not important.
3:44:36
Bike
like (if (typeq x list) a b) is turned into (if (typeq x cons) a (if (typeq x null) a b)), so that if there's an earlier (typeq x cons) it can eliminate that part of the test
3:46:07
beach
That is why I don't think any THE or TYPEP or DECLARE should turn into the same TYPEQ.
3:47:11
beach
It seems to me very complicated to let TYPEQ handle everything, only to remove it later.
3:49:29
Bike
right now i'm not doing anything major to rock the boat. probably moving loop invariants will do more good than a lot of this stuff, but that doesn't mean it's irrelevant, i don't think
3:51:02
Bike
...moving code might also be easier with typeq, since it has known semantics, unlike a function call where there have to be annotations introduced or something
3:51:57
beach
The way I see it is that TYPEP needs to exist anyway. TYPEQ can handle a subset, and is used for type inference. I don't see the additional separate facility here, other than type inference, which we need for reasons of performance.
3:52:43
Bike
typeq is used for type inference but it also affects control flow based on types of objects, same as calls to typep
3:53:30
beach
So there is nothing wrong with a combination of TYPEQ and calls to TYPEP. No additional separate facility here.
3:55:49
beach
Yes, the compiler macro for TYPEP can be arbitrarily complex, so that it contains knowledge of what TYPEQ can handle and what it can't.
3:57:29
beach
It is even possible to factor out the code that splits up a type into what TYPEQ can handle and the rest.
3:58:26
beach
This code would be entirely implementation specific, thereby avoiding yet another customization mechanism in Cleavir.
4:01:27
beach
Maybe Cleavir could provide some default that is coupled with what the type inferencer can handle.
4:14:21
Bike
i already have a couple functions like compile-or-typeq, compile-and-typeq, etc. hir level but no big