Non-H98 crusade, contd.

[Seth Kurtzberg]

It appears to me that there are important questions that need to be 
settled, unless ghc is to become a language of its own, rather than an 
implementation.  There's nothing wrong with having ghc specific 
features, but only if this is done on purpose.  Lots of things can 
result from such a discussion.  Maybe there isn't a consensus because 
there are really two necessary constructs rather than one.  Perhaps a 
consensus can be reached that allows one language extension to handle 
the requirements that have been exposed during the process of developing 
the libraries.

Would it not be a good idea to CC these messages onto whichever list is 
directly concerned with language extensions and changes?  The issues may 
be exposed by library development, but they are clearly of interest to 
both the language developers and the library developers.

ross at soi.city.ac.uk wrote:

>On Sat, Feb 26, 2005 at 08:00:22PM -0500, ajb at spamcop.net wrote:
>  
>
>>Quoting ross at soi.city.ac.uk:
>>    
>>
>>>Indeed.  Of all the extensions implemented by both GHC and Hugs, the only
>>>ones that seem ready are
>>>
>>>- rank 2 type signatures, and
>>>
>>>- polymorphic components for data constructors (giving them rank 2 types).
>>>      
>>>
>>Off the top of my head:
>>
>>- multi-parameter type classes
>>    
>>
>
>Reasonable in themselves, but limited in usefulness without some scheme to
>deal with overlapping instances, which doesn't seem settled at this time.
>
>  
>
>>- pattern guards
>>    
>>
>
>GHC only
>  
>
True, it is ghc only.  One of the advantages of developing additions to 
the standard that allow this usage and define it in a precise way.  If 
pattern guards are important (I personally think they are), then they 
should be formally designated as either an GHC extension to the language 
or a valuable extension that deserves to become part of a standard that 
compiler developers and library developers (both GHC and non-GHC) can 
reach a consensus.  This would, in this particular case, result in a 
very interesting discussion.  Do they truly make the language richer, or 
are there other equally effective ways to do the same thing?  It is 
evident that the GHC developers added this feature because they believe 
that it is an important extension to the language.

>  
>
>>- scoped type variables
>>    
>>
>
>Different treatment in GHC and Hugs.  Can you point at a formal calculus
>corresponding to the version in GHC?
>
>  
>
>>- recursive "do"
>>    
>>
>
>The treatment of recursion isn't obviously ideal: conflicts with ordinary
>do, and the semantics depends on the dependency analysis.
>  
>
Then this is a good opportunity to define the syntax and semantics of 
this facility that can be uniformly implemented in a non-ambiguous way 
that does not break the H98 do syntax.  Since do is basically a 
shorthand for a more complex and unwieldy coding, it might be logical to 
map a typical recursive do onto syntax that does not rely on do.  (In 
H98 everything that "do" can do can be done without "do".  (That has to 
be a candidate for worst sentence of the year.  :)  )

If the semantics is not deterministic, that is an obvious case where a 
consensus of how recursive do works is certainly needed.  I agree with 
Ross that this isn't a settled question; but IMHO it needs to be 
settled.  One core principle of functional programming in general and 
Haskell in particular is that you _know_ what your code will do.  If 
recursive "do" is an important feature (I believe that most Haskell 
people would agree that it is), then the behavior has to be consistent, 
or it has to be disallowed in situations where it introduces 
non-determinism.  I'm not knowledgeable enough to know whether that can 
be discovered at compile time.  Clearly it is a complex issue and not 
trivial to implement, but, also clearly, it is currently being used and 
the results are acceptable to the library developer.

I'd be very interested to know specifically why and under what 
circumstances the semantics is different.  Not from the compiler 
perspective (Ross states that the semantics depend on the dependency 
analysis) but from the perspective of the coder.  What are the possible 
semantics?  Is the ambiguity common or rare?  What happens if the 
library developer assumes one interpretation and the compiler generates 
a different one?

>>- data declarations with no constructors
>>    
>>
>
>Minor, but harmless.
>
>  
>
>>- constraints on typeclass methods
>>
>>- instances on type synonyms
>>    
>>
>
>Yes, these two and the relaxation of polymorphic recursion should have
>been in H98.
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>
>!DSPAM:4221288d198032093425033!
>
>  
>