On Tue, Jun 28, 2005 at 11:30:04AM -0400, Jim Apple wrote:
Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal.
I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together.
Why remove a feature from a product? Why not, instead, just choose to not use it?
implicit parameters are inherently broken according to some people (including me). There is no reason to remove them immediatly, but if it ever comes up that the code for them is holding back some other change, I would say dump them rather than try to work around or modify it. However, I would like to explore linear parameters more. I think a main issue with them is that they are mixed in with implicit parametrs and hence share their problems. An extension I was considering for jhc goes like this: in addition to normal variables, you may have linear variables which start with a %. linear variables may be used and bound exactly like normal variables. The only differences are as follows. linear variables automatically get a (Splittable a) constraint, they must be in class Splittable. and the following desugaring occurs. f %vs x y = g %vs <> h %vs z where z = name %vs x + y becomes f _vs x y = g _vs1 <> h _vs2 y x where z = name _vs3 x + y (_vs1,_nvs1) = split _vs (_vs2,_nvs2) = split _nvs1 (_vs3,_nvs3) = split _nvs2 where _vs is some unique name. basically the transformation is to change a linear variable to a normal one, replace each occurance of the linear variable with a unique name, bind the unique names to split versions of of the original ,now normal, binding. I think this gives all the advantages of linear parameters with a much simpler binding and semantics. an example of how this might be used is renameTerm %ns (EAp a b) = EAp (renameTerm %ns a) (renameTerm %ns b) renameTerm %ns (Let v e) = Let v' (renameTerm %ns e) where v' = rename v newname (newname:_) = %ns -- pull off first element of namesupply ... this assumes %ns is an infinite list of unique names. - note that %ns and ns are completly different variables with no relation. - any binding whether a let, where, function argument or monad generator can create a linear variable as long as it is in class Splittable, they are not special in any way. - The desugaring is really simple - there is no implied order of evaluation or modification of function structure like with monads. - none of the implicit parameter oddness. Comments? and yes, I know the term 'variable' is a misnomer when dealing with haskell :) John -- John Meacham - ⑆repetae.net⑆john⑈