On 8/8/07, Philippa Cowderoy wrote:

On Wed, 8 Aug 2007, peterv wrote: {... An editor that can be configured to display various inferred details, annotations and desugarings in the middle of the source would be useful for all kinds of purposes, and certainly not just to newbies!

...} I couldn't agree more.. that would be a godsend to have that .. One would think that the code to translate has to be in the compiler code, though I doubt that it does so to a readable format.. oh well. gene

I can't agree with your point about Haskell being (just) a prototype language (assuming that's what you meant). If that's the case, it won't last very long. Languages need to be something you can write real, practical applications in. Fortunately, Haskell isn't just a prototype language. I'm running a Haskell program (xmonad) every minute I'm working on my computer, and it's better than the C program (ion) that it replaced (with a code base about 1/40th the size). I'm sure Haskell isn't suitable for all application domains yet, but there's plenty of domains in which it can make its mark, and the frontier is going to keep getting pushed back. Mike Hugh Perkins wrote:

On 8/9/07, *peterv* mailto:bf3@telenet.be> wrote:

IMHO and being a newbie having 20 years of professional C/C++/C# experience but hardly any Haskell experience, I agree with this… I find the monad syntax very confusing, because it looks so much like imperative code, but it isn't. Personally I also liked the Concurrent Clean approach, although this also introduced extra syntax for the compiler, while 'cmd1 >>= \x…' does not. You have to type more, but you see much clearer what is going on.

Yeah, I kind of agree too. The only way I figured out sortof how to use Monads was to write everything out in >>= syntax. It was longer and uglier, but it made more sense.

That said, I sortof see Haskell as a prototype language, whose good points will be added into other languages. Every program needs to have a prototype, and Haskell is that.

So, whilst I'm tempted to add: an easy language needs to have only a single way of doing anything, so throwing away the "do" syntax makes the language easier by reducing the number of things to learn, actually for a prototype language, the rule is probably "anything goes", and then the best ideas get added to the non-prototype language later on.

------------------------------------------------------------------------

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 8/9/07, Benjamin Franksen wrote:

Donn Cave wrote:

...

(I have a soft spot for O'Haskell, but alas I must be nearly alone on that.)

You are /not/ alone :-) I always found it very sad that O'Haskell and also its sucessor Timber (with all the good real-time stuff added) died the 'quick death' of most research languages.

There is also RHaskell, which implements an O'Haskell-like system as a Haskell library. http://www.informatik.uni-freiburg.de/~wehr/haskell/

On 8/9/07, Benjamin Franksen wrote:

David Menendez wrote:

...

There is also RHaskell, which implements an O'Haskell-like system as a Haskell library.

http://www.informatik.uni-freiburg.de/~wehr/haskell/

Thanks for the pointer, I didn't know about this. Will take a look.

Perhaps a wiki page is in order. Reactive objects are an appealing way to organize programs, but there isn't much information on-line about people's experience with them.

On 9 Aug 2007, at 8:41 am, David Roundy wrote:

I may be stating the obvious here, but I strongly prefer the do syntax. It's nice to know the other also, but the combination of do +indenting makes complicated code much clearer than the nested parentheses that would be required with purely >>= syntax.

Er, what nested parentheses would those be? do e => e do e => e >> rest rest' do p <- e => e >>= \p -> rest rest' do let d => let d in rest rest' We get extra >>, >>=, \, ->, and "in" tokens, but no new parentheses. The example in the Report makes this clear: do putStr "x: " l <- getLine return (words l) desugars to putStr "x: " >> getLine >>= \l -> return (words l) with no extra parentheses. [Not that this actually works in GHC 6; the implied flush isn't done.]

On Thu, Aug 09, 2007 at 04:02:05PM +1200, ok wrote:

On 9 Aug 2007, at 8:41 am, David Roundy wrote:

...

I may be stating the obvious here, but I strongly prefer the do syntax. It's nice to know the other also, but the combination of do +indenting makes complicated code much clearer than the nested parentheses that would be required with purely >>= syntax.

Er, what nested parentheses would those be?

do x1 <- e1 if x1 then do x2 <- e2 xx <- if x2 then e3 else do x4 <- e4 x5 <- e5 e6 x4 x5 e7 xx x1 else do x8 <- e8 x9 <- e9 e10 x8 x9 x1 x11 would become something like e1 >>= \x1 -> if x1 then e2 >>= \x2 -> if x2 then e3 else e4 >>= \x4 -> e5 >>= \x5 -> e6 x4 x5 >>= (flip e7) x1 else e8 >>= \x8 -> e9 >>= \x9 -> e10 x8 x9 x1 >> x11 except that you'd have to figure out where to add parentheses. I'm sure I'd end up writing extra parentheses, but if you put in the minimal number of parentheses, then I doubt I'd be able to read the code. If you only consider the case of trivial code, then you're right, there are no extra parentheses required. This is the beauty of the do notation, it allows one to write actual real complicated monadic code in a form that is actually comprehensible. -- David Roundy Department of Physics Oregon State University

David Roundy wrote:

On Wed, Aug 08, 2007 at 02:20:39PM -0400, Paul Hudak wrote: As long as the sugar has a pretty obvious desugaring (which I seem to recall it did), I don't see how it's likely to make things worse. And

Some people are arguing that the desugaring isn't obvious. Although I like the proposal to start with, I am beginning to be convinced by those arguments. For example:

do foo x

can be simplified to

foo x

under the new proposals

do x <- bar y foo x

would shorten to

do foo (<- bar y)

and now you really really want to remove the do, to get simply

foo (<- bar y)

but that would be illegal. The new sugar is going to remove all kinds of substitution and simplification lemmas that we have got used to. There is also the fact that if : foo x = bar x x then you call foo monadically as in do foo (<- baz) You can no longer "replace foo with its definition", because if replace that with do bar (<- baz) (<- baz) ...that means something rather different :( A third example is with nested dos: do x <- bar y baz something $ do foo x is not the same as do baz something $ do foo (<- bar y) Jules

On Thu, Aug 09, 2007 at 11:52:17AM -0700, David Roundy wrote:

On Thu, Aug 09, 2007 at 02:08:20PM +0100, Jules Bean wrote:

*snip*

...

A third example is with nested dos:

do x <- bar y baz something $ do foo x

is not the same as

do baz something $ do foo (<- bar y)

Again, it all comes down to whether the "find the nearest do" is obvious. It seems pretty obvious to me. And I like the idea of someone just implementing this, and then those of us to whom it appeals can try it. I've longed for something like this (mostly for monadic ifs and cases) for quite a while now...

Funny, I've been longing for the monadic case (and if) for quite a while. A mondic case is simple, it's handy, and you don't have to worry about lots of interactions caseM e of alts ==> e >>= \x -> case x of alts I'm convinced this would be plenty useful on its own, and also that trying to design any more comprehensive syntax quickly gets really tricky. The basic problem seems to be that functions can expect either monadic or pure arguments, and return pure or monadic values, so there are at least three possible conversion you might want at each application (considering pure<->pure and monadic<->monadic the same). Defaulting to "make things work" requires type information, and doesn't seem nearly so simple if you consider that programmers might actually want to pass around actions of the monad they are running in as values (Setting GUI callbacks, using [] for String processing, etc). Actually, deciding which tranformation gets juxtaposition and how to recurse into subterms seems to give a design space that might have reasonable solutions. More on that in a latter message.

...

There is also the fact that if : foo x = bar x x

then you call foo monadically as in

do foo (<- baz)

You can no longer "replace foo with its definition", because if replace that with

do bar (<- baz) (<- baz)

...that means something rather different :(

Again, this seems obvious, and it doesn't seem like "replace foo with its definition" is something I think of.

One of the great things about haskell is how completely naive you can be when you "replace foo with its definition", and still do valid equational reasoning. It would be sad if substituting a parenthesized subterm of something that looked like an expression wasn't valid. (expanding a definition can change sharing, but at least it's denotationally equivalent). The only slightly tricky things now are remembering that x <- exp does not define x to be exp, and what to expand a class method to. I think I'd be happier if there was some bracketing around the expression to be transformed, to warn you to again be cautious and fearful about transforming your code. Brandon

On Thu, Aug 09, 2007 at 08:45:14PM +0200, Benjamin Franksen wrote:

David Roundy wrote:

...

Several times since reading the beginning of this discussion I've wished I had the new syntax so I could write something like:

do if predicateOnFileContents (<- readFile "foo") then ...

instead of either

do contents <- readFile "foo" if predicateOnFileContents contents then ...

or (as you'd prefer)

readFile "foo" >>= \contents -> if predicateOnFileContents contents then ...

Isn't this problem, namely being forced to name intermediate results, also solved by some sort of idiom bracket sugar, maybe together with the lambda case proposal? I would prefer both very much to the proposed (<- action) syntax for the same reasons that e.g. Jules Bean nicely summarized.

I'm not familiar with the lambda case proposal, and don't know what you mean by idiom bracket sugar, but I haven't had an idea (or heard of one) that was nearly so elegant as the (<- action) proposal, which neatly allows one to lift any existing pure function or syntactic construct (except lambda expressions?) into a monad. i.e. we don't need to define a separate 'if', 'case', etc, and we don't need liftM, liftM2, liftM3, liftM4andahalf, all of which are subsumed by a single pretty syntax. The only cost is that this syntax relies on the do notation, and thus makes the desugaring of that do notation slightly more complicated when used. -- David Roundy Department of Physics Oregon State University

There's been lots of interesting stuff on this thread. Does anyone feel up to summarizing it on a Wiki page, for others to polish? At least part of that page should comprise a compact specification of what the (<- ) proposal is; but there have been lots of other suggestions. Otherwise it'll all get submerged by next month's excitements. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- | bounces@haskell.org] On Behalf Of Benjamin Franksen | Sent: 09 August 2007 21:31 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] Re: Re: a regressive view of support for | imperative programming in Haskell | | David Roundy wrote: | > On Thu, Aug 09, 2007 at 08:45:14PM +0200, Benjamin Franksen wrote: | >> David Roundy wrote: | >> > Several times since reading the beginning of this discussion I've | wished I | >> > had the new syntax so I could write something like: | >> > | >> > do if predicateOnFileContents (<- readFile "foo") then ... | >> > | >> > instead of either | >> > | >> > do contents <- readFile "foo" | >> > if predicateOnFileContents contents then ... | >> > | >> > or (as you'd prefer) | >> > | >> > readFile "foo" >>= \contents -> | >> > if predicateOnFileContents contents then ... | >> | >> Isn't this problem, namely being forced to name intermediate | results, | also | >> solved by some sort of idiom bracket sugar, maybe together with the | lambda | >> case proposal? I would prefer both very much to the proposed (<- | action) | >> syntax for the same reasons that e.g. Jules Bean nicely summarized. | > | > I'm not familiar with the lambda case proposal, | | http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase | | or, quoting from a recent post by Stefan O'Rear in this thread: | | > I think the CaseLambda proposal on the Haskell' wiki solves this one | > nicely. | > | > mexpr >>= case of | > p1 -> branch1 | > p2 -> branch2 | > | > You still have to use >>=, but you don't have to name the scrutinee | (and | > names are expensive cognitively). | | i.e. your example would become | | fmap predicateOnFileContents (readFile "foo") >>= case of | True -> ... | False -> ... | | (use liftM instead of fmap, if you prefer) | | > and don't know what you mean by idiom bracket sugar, | | As has been already mentioned in this thread, in | http://www.soi.city.ac.uk/~ross/papers/Applicative.html Conor McBride | and | Ross Paterson invent/explain a new type class that is now part of the | base | package (Control.Applicative). They also use/propose syntactic sugar | for | it, i.e. | | pure f <*> u1 <*> ... <*> un | | ~~> (| f u1 ... un |) | | (I just made up the symbols '(|' and '|)', the concrete syntax would | have to | be fixed by people more knowledgeable than me.) | | As to the pros and cons of (<- action) proposal, I think everything has | been | said. I'd vote for giving IdiomBrackets and/or LambdaCase a chance for | being implemented, too, so we can try and evaluate different ways to | simplify monadic code. | | One reason why I like IdiomBrackets is that they are more generally | applicable (no pun intended ;:) i.e. they would work not just for | Monads | but for anything in Applicative. (Of course, that is also their | weakness.) | Similary, LambdaCase has more applications than just simplifying | monadic | code by avoiding to name an intermediate result. | | Cheers | Ben | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Aug 13, 2007 at 04:35:12PM +0200, apfelmus wrote:

My assumption is that we have an equivalence

forall a,b . m (a -> m b) ~ (a -> m b)

because any side effect executed by the extra m on the outside can well be delayed until we are supplied a value a. Well, at least when all arguments are fully applied, for some notion of "fully applied"

(\a x -> a >>= ($ x)) ((\f -> return f) X) ==> (β) (\a x -> a >>= ($ x)) (return X) ==> (β) (\x -> (return X) >>= ($ x)) ==> (monad law) (\x -> ($ x) X) ==> (β on the sugar-hidden 'flip') (\x -> X x) ==> (η) X Up to subtle strictness bugs arising from my use of η :), you're safe. Stefan

On Mon, Aug 13, 2007 at 05:39:34PM +0200, apfelmus wrote:

Stefan O'Rear schrieb:

...

On Mon, Aug 13, 2007 at 04:35:12PM +0200, apfelmus wrote:

...

My assumption is that we have an equivalence

forall a,b . m (a -> m b) ~ (a -> m b)

because any side effect executed by the extra m on the outside can well be delayed until we are supplied a value a. Well, at least when all arguments are fully applied, for some notion of "fully applied" (\a x -> a >>= ($ x)) ((\f -> return f) X) ==> (β) (\a x -> a >>= ($ x)) (return X) ==> (β) (\x -> (return X) >>= ($ x)) ==> (monad law) (\x -> ($ x) X) ==> (β on the sugar-hidden 'flip') (\x -> X x) ==> (η) X Up to subtle strictness bugs arising from my use of η :), you're safe.

Yes, but that's only one direction :) The other one is the problem:

return . (\f x -> f >>= ($ x)) =?= id

Here's a counterexample

f :: IO (a -> IO a) f = writeAHaskellProgram >> return return

f' :: IO (a -> IO a) f' = return $ (\f x -> f >>= ($ x)) $ f ==> (β) return $ \x -> (writeAHaskellProgram >> return return) >>= ($ x) ==> (BIND) return $ \x -> writeAHaskellProgram >> (return return >>= ($ x)) ==> (LUNIT) return $ \x -> writeAHaskellProgram >> (($ x) return) ==> (β) return $ \x -> writeAHaskellProgram >> return x

Those two are different, because

clever = f >> return () = writeAHaskellProgram clever' = f' >> return () = return ()

are clearly different ;)

I figured that wouldn't be a problem since our values don't escape, and the functions we define all respect the embedding... More formally: Projections and injections: proj ma = \x -> ma >>= \ fn' -> fn' x inj fn = return fn Define an equivalence relation: ma ≡ mb <-> proj ma = proj mb Projection respects equivalence: ma ≡ mb -> proj ma = proj mb (intro ->) ma ≡ mb => proj ma = proj mb (equiv def) proj ma = proj mb => proj ma = proj mb (assumption) Application: (@) ma1 = \x -> join (proj ma1 x) Application respects equivalence: ma1 ≡ ma2 -> (@) ma1 = (@) ma2 (intro ->) ma1 ≡ ma2 => (@) ma1 = (@) ma2 (β) ma1 ≡ ma2 => (\x -> join (proj ma1 x)) = (\x -> join (proj ma2 x)) (extensionality) ma1 ≡ ma2 => join (proj ma1 x) = join (proj ma2 x) (application respects = left) ma1 ≡ ma2 => proj ma1 x = proj ma2 x (application respects = right) ma1 = ma2 => proj ma1 = proj ma2 (lemma) Stefan

David Roundy wrote:

The only cost is that this syntax relies on the do notation, and thus makes the desugaring of that do notation slightly more complicated when used.

If I understand correctly, do blah f (do foo bar (<- action) ) blah has an ambiguity: which do-block is the action bound in? I can easily imagine myself being frustrated at having to refactor my code if the defined answer is not the one I want at the moment. Isaac