RE: Haskell-Cafe Digest, Vol 70, Issue 2

1 Jun 2009


      Sorry -- the vocabulary template is attached.
...
From: haskell-cafe-request@haskell.org
Subject: Haskell-Cafe Digest, Vol 70, Issue 2
To: haskell-cafe@haskell.org
Date: Mon, 1 Jun 2009 21:47:16 -0400
Send Haskell-Cafe mailing list submissions to
  haskell-cafe@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
  http://www.haskell.org/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
  haskell-cafe-request@haskell.org
You can reach the person managing the list at
  haskell-cafe-owner@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haskell-Cafe digest..."
Today's Topics:
1. Re: Missing a "Deriving"? (Daniel Fischer)
   2. Re: Bool as type class to serve EDSLs. (Claus Reinke)
   3. Re: ANN: new version of uu-parsinglib (S. Doaitse Swierstra)
   4. Re: Re: Error message reform (Claus Reinke)
   5. Re: Re: Error message reform (was: Strange type	errorwith
      associated type synonyms) (Claus Reinke)
   6. Re: Missing a "Deriving"? (michael rice)
   7. Re: Bool as type class to serve EDSLs. (Sebastian Fischer)
   8. Checking a value against a passed-in constructor? (Dan Cook)
   9. Re: Checking a value against a passed-in constructor?
      (Jason Dagit)
  10. Re: Missing a "Deriving"? (michael rice)
  11. Re: Missing a "Deriving"? (Ross Mellgren)
  12. Re: Missing a "Deriving"? (michael rice)
  13. Re: Missing a "Deriving"? (Ross Mellgren)
  14. Re: Missing a "Deriving"? (michael rice)
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 Jun 2009 19:51:35 +0200
From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Missing a "Deriving"?
To: haskell-cafe@haskell.org
Message-ID: <200906011951.35775.daniel.is.fischer@web.de>
Content-Type: text/plain;  charset="iso-8859-15"
Am Montag 01 Juni 2009 19:02:36 schrieb michael rice:
...
All good so far, but then tried to convert Failable from Computation to
Monad
instance Monad Failable where
    return = Success
    fail = Fail
    >>= (Success x) f = f x
    >>= (Fail s) _ = Fail s
    mplus (Fail _) y = y
    mplus x _ = x
and got the following error.
Prelude> :l graph5
[1 of 1] Compiling Main             ( graph5.hs, interpreted )
graph5.hs:34:4: parse error on input `>>='
Failed, modules loaded: none.
Prelude>
When you use an operator in prefix position, you must enclose it in parentheses, like you 
must enclose a function in backticks if you use it infix.
So the definition of (>>=) should read
(>>=) (Success x) f = f x
    (>>=) (Fail s) _ = Fail s
or, defining it in infix position,
    (Success x) >>= f = f x
    (Fail s) >>= _ = Fail s
...
Complete code follows.
Michael
------------------------------
Message: 2
Date: Mon, 1 Jun 2009 19:22:10 +0100
From: "Claus Reinke" 
Subject: Re: [Haskell-cafe] Bool as type class to serve EDSLs.
To: "haskell Cafe" 
Message-ID: <76CE077128014A86A2D61E5918F8BFE8@cr3lt>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
  reply-type=original
...
...
Do you argue that overloading logical operations like this in Haskell
sacrifices type safety? Could programs "go wrong" [1] that use such
abstractions?
If I understand your point correctly, you are suggesting that such programs
are still type safe.  I agree with the claim that such features are
detrimental in practice though.  Instead of lumping it with type safety,
then what do we call it?  I think I've heard of languages that do such
conversions as "weakly" typed.  Really the issue is with implicit
conversions, right?
Isn't it merely a matter of balance? In order for typed programs not
to go "wrong", one has to define "right" and "wrong", and devise a type
system that rules out anything that might go "wrong", usually at the
expense of some programs that might go "right".
Advanced type system features like overloading take that unused space 
and devise ways to redirect code that would go "wrong" (in simpler 
systems) to go "right" in useful new ways (eg: adding two functions or 
matrices or .. does not have to be "wrong", there are interpretations in 
which all of these make perfect sense, and Haskell can express many
of them).
What is happening then is that more and more of the previously "wrong"
space is filled up with meaningful ways of going "right", until nearly every
syntactically valid program goes somewhere. That can make for an
extremely expressive and powerful language, but it renders the naive
notion of going "wrong" or "right" rather meaningless: "wrong" just
means we haven't figured out a meaningful way to interpret it, and 
going "right" can easily be a far cry from where you wanted it to go.
Claus
PS. this problem can be made worse if the implicit conversions
    aren't consistent, if small "twitches" in source code can lead to 
    grossly different behaviour. There is a fine line between advanced
    and uncontrollable, and opinions on what side of the line any given
    definition is on can differ.
------------------------------
Message: 3
Date: Mon, 1 Jun 2009 20:27:05 +0200
From: "S. Doaitse Swierstra" 
Subject: Re: [Haskell-cafe] ANN: new version of uu-parsinglib
To: Ross Paterson 
Cc: haskell-cafe@haskell.org
Message-ID: <8F2D399B-451A-45F4-9FE1-B7F5145C3B91@swierstra.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
And rename "empty" to "fail"? You managed to confuse me since I always  
use pSucceed to recognise the empty string.
Doaitse
On 1 jun 2009, at 01:21, Ross Paterson wrote:
...
On Sun, May 31, 2009 at 09:40:38PM +0200, S. Doaitse Swierstra wrote:
...
A new version of the uu-parsinglib has been uploaded to hackage. It  
is
now based on Control.Applicative where possible.
Be warned that functions like some and many will be redefined in the
future.
Perhaps we should make some and many methods of Alternative, <* and *>
methods of Applicative and <$ a method of Functor, all with the  
current
definitions as defaults.  (John Meacham was also asking for the first
of these.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
------------------------------
Message: 4
Date: Mon, 1 Jun 2009 19:49:44 +0100
From: "Claus Reinke" 
Subject: Re: [Haskell-cafe] Re: Error message reform
To: 
Message-ID: 
Content-Type: text/plain; format=flowed; charset="UTF-8";
  reply-type=response
...
It's too wordy, but it's a start. This is also prime ground for wanting 
to have configurable levels of error reports, since some users will find 
it helpful to see both types but others will find it confusing.
Indeed. For this simple example, I find Hugs' message nearly optimal,
but as one could just as well construct examples where GHC's message 
was nearly optimal, I've tried instead to extend the example, until neither 
Hugs nor GHC gives an optimal message. Even so, it is worth comparing 
the two, and their complementary approaches to the problem:
t = (let q=0 in(\y->(\x->(\z->let r=1 in x z))) ()) :: (a->b)->(a->a)
D:\home\Haskell\tmp\desktop\errormessages.hs:2:41:
    Couldn't match expected type `a' against inferred type `b'
      `a' is a rigid type variable bound by
          an expression type signature
            at D:\home\Haskell\tmp\desktop\errormessages.hs:2:56
      `b' is a rigid type variable bound by
          an expression type signature
            at D:\home\Haskell\tmp\desktop\errormessages.hs:2:59
    In the expression: x z
    In the expression: let r = 1 in x z
    In the expression: (\ z -> let r = 1 in x z)
ERROR file:.\errormessages.hs:2 - Inferred type is not general enough
*** Expression : let {...} in (\y -> \x -> \z -> let {...} in x z) ()
*** Expected type : (a -> b) -> a -> a
*** Inferred type : (a -> a) -> a -> a
GHC delivers its messages from in-the-middle of its typing process,
which one hopes might give as little information as neccessary to
identify the issue, without irrelevant context. It then tries to explain
that information nicely, followed by some value-level context.
Hugs delivers its messages from on-the-outside-looking-in, which one
hopes might give the maximum potentially relevant information. It makes
no attempt to cushion the blow.
In practice, neither approach works all the time, and even for this
tiny contrived example, one would have to engage in some "type
debugging" (inserting type signatures, to trigger type-level printfs;
commenting out large parts of code to see whether they contribute
to the issue; ..) to figure it out.
Note that both approaches are fairly precise in locating the error
at the type level - it is the cross-reference from type to value level
that runs into trouble, especially if the former is only implicit in the
latter (which is why type debugging by adding signatures helps).
...
For really intricate type hacking, even this isn't enough because the 
programming errors often happen far from where the type errors are 
finally caught. In an ideal world, ghc could dump the entire proof 
forest generated by inference, so an external tool[1] could be used to 
browse through it and track the complete history of where inferred types 
came from. This gives a partial view of the inferred types for a 
compilation unit, something I've often wanted (rather than the manual 
comment/reload/uncomment routine). The proof forest could even be used 
as an interlingua over which people can write filters to generate 
messages they find most helpful.
Yes, most research papers on this ended up suggesting visual representations
and separation between generating and presenting/querying error information.
...
Ah the joys of ideal worlds... ;)
"if you don't have a dream, how you gonna have a dream come true?" (Bloody Mary)
Claus
------------------------------
Message: 5
Date: Mon, 1 Jun 2009 20:00:09 +0100
From: "Claus Reinke" 
Subject: Re: [Haskell-cafe] Re: Error message reform (was: Strange
  type	errorwith associated type synonyms)
To: 
Message-ID: <8C39CAA7170D479D88613F7F77920916@cr3lt>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
  reply-type=response
...
I once thought, that error messages must be configurable by libraries, 
too. This would be perfect for EDSLs that shall be used by non-Haskellers.
Yes, that is a problem.
...
But I have no idea how to design that.
There was some work in that direction in the context of the Helium
project. See the publication lists of Bastiaan Heeren and Jurriaan Hage:
http://people.cs.uu.nl/bastiaan/#Publications
http://www.cs.uu.nl/research/techreps/aut/jur.html
Claus
------------------------------
Message: 6
Date: Mon, 1 Jun 2009 14:30:00 -0700 (PDT)
From: michael rice 
Subject: Re: [Haskell-cafe] Missing a "Deriving"?
To: haskell-cafe@haskell.org,	Daniel Fischer
  
Message-ID: <789959.35516.qm@web31103.mail.mud.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Got it.
Thanks!
Michael
--- On Mon, 6/1/09, Daniel Fischer  wrote:
From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Missing a "Deriving"?
To: haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 1:51 PM
Am Montag 01 Juni 2009 19:02:36 schrieb michael rice:
...
All good so far, but then tried to convert Failable from Computation to
Monad
instance Monad Failable where
    return = Success
    fail = Fail
    >>= (Success x) f = f x
    >>= (Fail s) _ = Fail s
    mplus (Fail _) y = y
    mplus x _ = x
and got the following error.
Prelude> :l graph5
[1 of 1] Compiling Main             ( graph5.hs, interpreted )
graph5.hs:34:4: parse error on input `>>='
Failed, modules loaded: none.
Prelude>
When you use an operator in prefix position, you must enclose it in parentheses, like you 
must enclose a function in backticks if you use it infix.
So the definition of (>>=) should read
(>>=) (Success x) f = f x
    (>>=) (Fail s) _ = Fail s
or, defining it in infix position,
    (Success x) >>= f = f x
    (Fail s) >>= _ = Fail s
...
Complete code follows.
Michael
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

R J

tags

participants (1)