Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}

_{Nov}

_{Dec}


2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(8) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(8) 
_{Nov}
(1) 
_{Dec}

2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2005 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2006 
_{Jan}
(2) 
_{Feb}
(24) 
_{Mar}
(263) 
_{Apr}
(115) 
_{May}
(88) 
_{Jun}
(215) 
_{Jul}
(408) 
_{Aug}
(247) 
_{Sep}
(334) 
_{Oct}
(174) 
_{Nov}
(131) 
_{Dec}
(112) 
2007 
_{Jan}
(121) 
_{Feb}
(62) 
_{Mar}
(122) 
_{Apr}
(286) 
_{May}
(209) 
_{Jun}
(241) 
_{Jul}
(203) 
_{Aug}
(156) 
_{Sep}
(236) 
_{Oct}
(145) 
_{Nov}
(375) 
_{Dec}
(165) 
2008 
_{Jan}
(11) 
_{Feb}
(18) 
_{Mar}
(58) 
_{Apr}
(83) 
_{May}
(26) 
_{Jun}
(4) 
_{Jul}
(7) 
_{Aug}
(102) 
_{Sep}
(30) 
_{Oct}
(65) 
_{Nov}
(4) 
_{Dec}
(6) 
2009 
_{Jan}
(103) 
_{Feb}
(107) 
_{Mar}
(150) 
_{Apr}
(402) 
_{May}
(141) 
_{Jun}
(194) 
_{Jul}
(30) 
_{Aug}
(4) 
_{Sep}
(14) 
_{Oct}
(59) 
_{Nov}
(34) 
_{Dec}
(10) 
2010 
_{Jan}
(24) 
_{Feb}
(12) 
_{Mar}
(14) 
_{Apr}
(1) 
_{May}
(9) 
_{Jun}

_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}
(15) 
_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(17) 
_{Nov}
(1) 
_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(1) 
3
(1) 
4
(24) 
5
(6) 
6
(9) 
7
(7) 
8
(2) 
9

10
(14) 
11
(15) 
12
(24) 
13
(47) 
14
(28) 
15
(1) 
16
(3) 
17

18
(9) 
19
(25) 
20
(17) 
21
(12) 
22
(1) 
23
(3) 
24
(13) 
25
(5) 
26
(8) 
27
(16) 
28
(14) 
29
(4) 
30
(23) 
From: skaller <skaller@us...>  20060922 18:53:43

I'm still trying to find a good way to model typeclasses. Here's how the constraints work: given typeclass P[r,s] { .. fun p: r * s>bool; .. } If a function has: fun f[u,v with P[h[u,v],k[u,v]]] then in the body of the function we're going to do: open P[h[u,v],k[u,v]]; where h,k are some types expressed in terms of u and v, so that the specialisation of P with substitutions indicated positionally is available for overload: r>h[u,v], s>k[u,v] thus we have fun p: h[u,v] * k[u,v] > bool; available for overload. Now, when we CALL a function: fun g[a,b with P[m[a,b], n[a,b]] (x:a*b) ... like g x matching the type of the argument of the call x against the signature a*b yields a substitution: a>c[u,v], b>d[u,v] We plug that into the required typeclass specialisation and get P[m',n'] where m' = m[c[u,v],d[u,v]], n'=... that is, m',n' are specialised and reexpressed in terms of u,v. We then match: typematch P[h,k] with P[m',n'] => 1  _ > 0 // caller called which is done by separately matching m' against h, and n' against k. If the match passes we know that P[h,k] is more specialised than P[m',n']. We also know P[m',n'] is more specialised than P[m,n], since it was obtained by actually specialising it so P[h,k] is more specialised than P[m,n], and indeed the substitution required to prove that is just the composition of the two unifiers. Now, *assume* we have an instance satisfying P[h,k], then it must also satisfy P[m,n], because P[h,k] is imposing tighter restrictions on the form of its arguments. Put another way, P[h,k] is a subtype of P[m,n]. Therefore it is safe to call the function, because we have proved P[h,k] implies P[m,n] In particular, the constraint: typematch P[h,k] with P[m',n'] => 1  _ > 0 assures the condition. For a dumb example: fun g[r,s with P[r,s]] (x:r * s)=> .. fun f[ with P[int,long] ] (x:int * long) => g x; is safe, because matching the argument type int * long with the function signature r * s we obtain the substitution r > int, s>long and then typematch P[int,long] with P[r,s] => 1  _ > 0 beta reduces to typematch P[int,long] with P[int,long] => 1  _ > 0 and thence to 1, since clearly they match. P[r,s] is more general than P[int,long], which means the if the instantiator can find instance P[int,long] it will instantiate a copy of g for the call that also be using P[int,long]. Remember instantiation is nothing more than monorphising something polymorphic by plugging in substitutions, in particular, starting from the program roots, we substitute nonpolymorphic (ground) types all the way down every call chain, to find all the types we have to get the C++ code generator to manufacture  the substitutions always eliminate all the type variables because each one is expressed in terms of the previous one and the ground types (int, long etc) 'flow through'. This is why the somewhat surprising condition, that the called functions typeclass requirements must be more general, not more specialised. Actually it only makes sense: a nonpolymorphic function can call a polymorphic one, but a polymorphic function cannot call a nonpolymorphic one (except on constants). SO .. the 'proof' we need to do here is trivial (a couple of lines of code). The instantiator also does the same proofs, only it chains them together. The reason for doing the piecemeal proofs during overloading is to ensure the instantiators proof will succeed  it's supposed to be an instantiator, not a type checker. The big problem now for me is: (a) syntax specifying the 'typeclasses' to be used (b) adjusting the data structures to carry the information Although typeclasses play a role in specifying a constraint: P[h,k] implies P[m,n] the actual constraint is a cooperation between the callers typeclasses and the called function typeclasses: it isn't itself a constraint. More precisely, a typeclass is a generalisation of the Felix 'typeset' feature. A typeset like typedef ints = typesetof(int,long); isn't a constraint, however t:ints is a constraint 't in ints'. A typeclass generalises this notion: P[u,v] actually means u,v in P That is, it is a multiargument predicate. Strangely enough, the values for which P holds are precisely like typesets .. a finite set of type tuples (at least Haskell style typesets are nothing but a finite set of instances). However there is a difference: a predicate is just a check. Typesets do more than require checks .. they actually cause extra functions to be brought into scope. SO: I think I need to track the list of typeclasses a function uses, and separately, either make the type system handle predicates, or simply handle them manually: extract the type arguments of the predicates and unify corresponding arguments. Interestingly .. the unification engine and type system ALREADY handle predicates .. and have done so for years! Because the obvious representation of an abstract predicate is nothing more than an abstract polymorphic type: the encoding used for instances of C bindings such as: type vector[t] = ... vector[int] is `BTYP_inst (vector,[int]) and we can just put P[h,k] > `BTYP_inst (P, [h,k]) P[m',n'] > `BTYP_inst (P, [m',n']) and typematch P[h,k] with P[m',n'] => 1  _ > 0 will go through. In other words, there is a ready made way to 'type' typeclasses. Finally, there is one more thing to note: when we see P[int,long] in a called function, we do NOT require any instance of P in the calling functions type class list. Instead we need to see an instance P[int,long] in the environment. More generally, if we allow polymorphic instances such as P[t,t] in the environment, we know we can make P[int,int] so there is a match rule: typematch P[int,int] with P[t,t] => 1  .. as well. Note this is the REVERSE rule: the called signature is the match argument not the pattern. So to make overloading work, we have to have TWO environments: the caller function typeclasses and the called function environment, in which we have to search for all the instances .. and use overloading to select the most specialised (assuming we allow polymorphic typeclass instances). There are thus two ways to generalise a function's typeclass: from the callers typeclass list or the called function's own environment. I wonder how to disambiguate .. :)  John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net 