You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}
(4) 
_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(6) 
_{May}
(4) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}
(3) 
_{Nov}

_{Dec}

2004 
_{Jan}

_{Feb}
(1) 
_{Mar}
(14) 
_{Apr}
(71) 
_{May}
(93) 
_{Jun}
(17) 
_{Jul}
(62) 
_{Aug}
(25) 
_{Sep}
(42) 
_{Oct}
(43) 
_{Nov}
(51) 
_{Dec}
(70) 
2005 
_{Jan}
(15) 
_{Feb}
(20) 
_{Mar}
(1) 
_{Apr}
(29) 
_{May}
(18) 
_{Jun}
(27) 
_{Jul}
(71) 
_{Aug}
(114) 
_{Sep}
(89) 
_{Oct}
(177) 
_{Nov}
(107) 
_{Dec}
(54) 
2006 
_{Jan}
(165) 
_{Feb}
(111) 
_{Mar}
(138) 
_{Apr}
(99) 
_{May}
(78) 
_{Jun}
(85) 
_{Jul}
(104) 
_{Aug}
(97) 
_{Sep}
(276) 
_{Oct}
(313) 
_{Nov}
(65) 
_{Dec}
(35) 
2007 
_{Jan}
(21) 
_{Feb}
(143) 
_{Mar}
(136) 
_{Apr}
(174) 
_{May}
(99) 
_{Jun}
(11) 
_{Jul}
(225) 
_{Aug}
(54) 
_{Sep}
(118) 
_{Oct}
(44) 
_{Nov}
(31) 
_{Dec}
(9) 
2008 
_{Jan}
(1) 
_{Feb}
(1) 
_{Mar}
(21) 
_{Apr}

_{May}
(23) 
_{Jun}

_{Jul}
(3) 
_{Aug}
(4) 
_{Sep}
(5) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2009 
_{Jan}
(1) 
_{Feb}
(7) 
_{Mar}
(38) 
_{Apr}
(75) 
_{May}
(12) 
_{Jun}
(34) 
_{Jul}

_{Aug}
(6) 
_{Sep}
(20) 
_{Oct}

_{Nov}
(13) 
_{Dec}
(1) 
2010 
_{Jan}
(26) 
_{Feb}

_{Mar}

_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}
(3) 
_{Oct}
(140) 
_{Nov}
(88) 
_{Dec}
(63) 
2011 
_{Jan}
(41) 
_{Feb}
(35) 
_{Mar}
(31) 
_{Apr}
(20) 
_{May}
(4) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(11) 
_{Nov}
(30) 
_{Dec}
(8) 
2012 
_{Jan}
(28) 
_{Feb}
(35) 
_{Mar}
(27) 
_{Apr}
(55) 
_{May}
(57) 
_{Jun}
(23) 
_{Jul}
(18) 
_{Aug}
(86) 
_{Sep}
(20) 
_{Oct}
(16) 
_{Nov}
(65) 
_{Dec}
(59) 
2013 
_{Jan}
(65) 
_{Feb}
(77) 
_{Mar}
(51) 
_{Apr}
(16) 
_{May}
(46) 
_{Jun}
(19) 
_{Jul}
(18) 
_{Aug}
(4) 
_{Sep}
(18) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}
(38) 
2014 
_{Jan}
(71) 
_{Feb}
(48) 
_{Mar}
(32) 
_{Apr}
(6) 
_{May}
(17) 
_{Jun}
(2) 
_{Jul}
(1) 
_{Aug}
(82) 
_{Sep}
(40) 
_{Oct}
(2) 
_{Nov}
(8) 
_{Dec}
(5) 
2015 
_{Jan}
(4) 
_{Feb}
(12) 
_{Mar}
(23) 
_{Apr}
(12) 
_{May}

_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(15) 
2
(19) 
3
(5) 
4
(21) 
5
(15) 
6
(2) 
7
(14) 
8
(24) 
9
(14) 
10
(23) 
11
(13) 
12
(12) 
13
(8) 
14
(1) 
15
(3) 
16
(3) 
17
(1) 
18
(11) 
19
(2) 
20
(1) 
21
(1) 
22
(3) 
23

24
(2) 
25
(16) 
26
(7) 
27
(11) 
28
(11) 
29
(11) 
30
(7) 
From: skaller <skaller@us...>  20060922 12:37:38

On Fri, 20060922 at 11:30 +0200, Klas I wrote: > I must admit that a lot of this stuff is over my head, but I have question. > In the wiki you mention: > > typeclass X[u,v] { fun f(x:u,y:v) .. > > which reminds me about the typeclasses I've used in Haskell. Yes, it's based on them. > Is it also possible to put == in typeclass X? If you mean the equality operator, yes, it's just another function.  John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net 
From: Klas I <klas.ivarsson@br...>  20060922 09:31:11

I must admit that a lot of this stuff is over my head, but I have question. In the wiki you mention: typeclass X[u,v] { fun f(x:u,y:v) .. which reminds me about the typeclasses I've used in Haskell. Is it also possible to put == in typeclass X? > > From: skaller <skaller@...> > Date: 2006/09/22 fr AM 02:34:24 CEST > To: felixlanguage@... > Ämne: [Felixlanguage] Type constraints > > It is now possible to write type constraints like this: > >  > fun ff[t,k where t==k ]: t * k > t = "$1+$2"; > print$ ff$ 1,2; > print$ ff$ 1,2.0; // should fail >  > > The first case passes because int == int, > the second fails because int != double. > > A constraint is any type expression. If it reduces > to 0 (void), the constraint fails. If it reduces > to 1 (unit), the constraint passes. > > If it fails to reduce, you will currently get an error. > It's possible this should be treated in some cases > as a failure (not sure). > > The 'where' constraints currently do NOT contribute > to type variable deduction (mainly because I'm lazy). > > The module Typing is now open and contains the following > useful operators: > > prefix infix meaning >  > eq == equality > land and logical and > lor or logical or > dom domain of a function > cod codomain of a function > prj1 first component of a pair > prj2 second component of a pair > > All these operators are defined using the typematch feature. > The following features are also available and provided by the > desugaring pass and the core type system: > > compl ~ categorical dual > proj_<n> n'th projection of a tuple (codomain of) > _isin _isin (elt,typeset) > _case_arg_<n> n'th injection of a sum (domain of) > > and of course the usual typematch and lamdba expressions. > > Typesets are created like: > > typesetof(int,long, float) > > and can be combined with infix  (union) and && (intersection) > operators. > > At present the family of operations is somewhat adhoc. > > Note the type system supports intersection types natively > but there's no notation for it! > > The following should hold: > > _isin (t,typesetof(y)) == > typematch t with  y => 1  _ => 0 endmatch > > but probably doesn't work. This is basically an encoding > of the logic/set theory isomorphism > > P(x) == x in { x  P(x) } > > The biggest problem, however, is that there is no 'tail' > and 'cons' operator for tuples such that > > t == cons (proj_n t, tail t) // where t is a tuple type > > I will add this, since it is necessary for recursive analysis > of tuples using typematches. A similar pair of operators is > required to analyse sum types, although it can be done > immediately using the categorical dual. > > Most interestingly .. we'd like to GET RID of these operators > by using polyadic programming. In particular 'cons' and > its dual are just two iterable type constructors. Another > one is function formation: here are the three listed: > > a * b * c * ... > a + b + c + ... > a > b > c > ... > > but we'd really like: > > a * b * c * .. = fold * (a, b, c ..) > a + b + c * .. = fold + (a, b, c ..) > a > b > c .. = fold > (a, b, c .. ) > > That is, we'd REALLY like to treat tuple, sum, and function > type constructors as ordinary type functions we can fold > over a type tuple. > > Since typematch has been modified to conform to Barry Jays maxim > "every expression is a pattern", we should be able to achieve > recursive type analysis of such data types generically with > pattern matching. > > For example you should be able to say > > all the components of the tuple are fast integers > > using 'filter', which in turn is encoded by recursive > desconstruction of a folded data type encoding. > > One of the key difficulties here is that tuples and sums > aren't associative, so that a tuple or sum type is NOT > built inductively (note that > is left associative). > > This basically requires a way to deconstruct a tuple > or sum type into a type tuple, and the operators > > head, tail, cons > > for type tuples. With some thought we should obtain > fully polyadic system! (This is the Holy Grail) > > Hmm .. I'm seeing how to do this now! > > Anyhow, we need the 'where' clause and 'specialisations' > to implement typeclasses. > >  > John Skaller <skaller at users dot sf dot net> > Felix, successor to C++: http://felix.sf.net > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys  and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Felixlanguage mailing list > Felixlanguage@... > https://lists.sourceforge.net/lists/listinfo/felixlanguage > 
From: skaller <skaller@us...>  20060922 00:34:36

It is now possible to write type constraints like this:  fun ff[t,k where t==k ]: t * k > t = "$1+$2"; print$ ff$ 1,2; print$ ff$ 1,2.0; // should fail  The first case passes because int == int, the second fails because int != double. A constraint is any type expression. If it reduces to 0 (void), the constraint fails. If it reduces to 1 (unit), the constraint passes. If it fails to reduce, you will currently get an error. It's possible this should be treated in some cases as a failure (not sure). The 'where' constraints currently do NOT contribute to type variable deduction (mainly because I'm lazy). The module Typing is now open and contains the following useful operators: prefix infix meaning  eq == equality land and logical and lor or logical or dom domain of a function cod codomain of a function prj1 first component of a pair prj2 second component of a pair All these operators are defined using the typematch feature. The following features are also available and provided by the desugaring pass and the core type system: compl ~ categorical dual proj_<n> n'th projection of a tuple (codomain of) _isin _isin (elt,typeset) _case_arg_<n> n'th injection of a sum (domain of) and of course the usual typematch and lamdba expressions. Typesets are created like: typesetof(int,long, float) and can be combined with infix  (union) and && (intersection) operators. At present the family of operations is somewhat adhoc. Note the type system supports intersection types natively but there's no notation for it! The following should hold: _isin (t,typesetof(y)) == typematch t with  y => 1  _ => 0 endmatch but probably doesn't work. This is basically an encoding of the logic/set theory isomorphism P(x) == x in { x  P(x) } The biggest problem, however, is that there is no 'tail' and 'cons' operator for tuples such that t == cons (proj_n t, tail t) // where t is a tuple type I will add this, since it is necessary for recursive analysis of tuples using typematches. A similar pair of operators is required to analyse sum types, although it can be done immediately using the categorical dual. Most interestingly .. we'd like to GET RID of these operators by using polyadic programming. In particular 'cons' and its dual are just two iterable type constructors. Another one is function formation: here are the three listed: a * b * c * ... a + b + c + ... a > b > c > ... but we'd really like: a * b * c * .. = fold * (a, b, c ..) a + b + c * .. = fold + (a, b, c ..) a > b > c .. = fold > (a, b, c .. ) That is, we'd REALLY like to treat tuple, sum, and function type constructors as ordinary type functions we can fold over a type tuple. Since typematch has been modified to conform to Barry Jays maxim "every expression is a pattern", we should be able to achieve recursive type analysis of such data types generically with pattern matching. For example you should be able to say all the components of the tuple are fast integers using 'filter', which in turn is encoded by recursive desconstruction of a folded data type encoding. One of the key difficulties here is that tuples and sums aren't associative, so that a tuple or sum type is NOT built inductively (note that > is left associative). This basically requires a way to deconstruct a tuple or sum type into a type tuple, and the operators head, tail, cons for type tuples. With some thought we should obtain fully polyadic system! (This is the Holy Grail) Hmm .. I'm seeing how to do this now! Anyhow, we need the 'where' clause and 'specialisations' to implement typeclasses.  John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net 