ANNOUNCE: GHC survey results

[John Meacham]

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⑈