One more 'do' pattern

older
Specific denotations for pure types

Bulat Ziganshin

28 Mar 2009 28 Mar '09

4:54 a.m.

Hello haskell-prime, as we know, the following code action x y >>= \v -> do can be shortened to following v <- action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element -> do ... or bracket createDialog destroyDialog $ \dialog -> do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element <-- for list do dialog <-- bracket createDialog destroyDialog do ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Show replies by date

Thomas Davie

28 Mar 28 Mar

5:05 a.m.

On 28 Mar 2009, at 09:54, Bulat Ziganshin wrote:

...

Hello haskell-prime,

as we know, the following code

action x y >>= \v -> do

can be shortened to following

v <- action x y

but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter:

for list $ \element -> do ...

or

bracket createDialog destroyDialog $ \dialog -> do ...

what about adding one more 'do' sugar that will allow to move variable name to the left, such as

for element in list do or with dialog in bracket createDialog destroyDialog do

or just

element <-- for list do dialog <-- bracket createDialog destroyDialog do

?

In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example). As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? Bob

Bulat Ziganshin

5:13 a.m.

New subject: Re[2]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 12:05:02 PM, you wrote:

...

In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example).

well, people already have problems understanding haskell, not only 'do' statements

...

As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax?

i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Thomas Davie

5:15 a.m.

New subject: Re[2]: One more 'do' pattern

On 28 Mar 2009, at 10:13, Bulat Ziganshin wrote:

...

Hello Thomas,

Saturday, March 28, 2009, 12:05:02 PM, you wrote:

...
In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example).

well, people already have problems understanding haskell, not only 'do' statements

...
As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax?

i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages

I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work. Bob

Bulat Ziganshin

5:24 a.m.

New subject: Re[4]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 12:15:37 PM, you wrote:

...

I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work.

what kind of problems you are solving? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Thomas Davie

5:34 a.m.

New subject: Re[4]: One more 'do' pattern

On 28 Mar 2009, at 10:24, Bulat Ziganshin wrote:

...

Hello Thomas,

Saturday, March 28, 2009, 12:15:37 PM, you wrote:

...
I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work.

what kind of problems you are solving?

Large GUI applications doing lots of 3D rendering. Bob

Bulat Ziganshin

5:38 a.m.

New subject: Re[6]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 12:34:05 PM, you wrote:

...

...
...
I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work.

what kind of problems you are solving?

...

Large GUI applications doing lots of 3D rendering.

and you have written GUI in FP style? with trees, d&d support and so on? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Thomas Davie

5:41 a.m.

New subject: Re[6]: One more 'do' pattern

On 28 Mar 2009, at 10:38, Bulat Ziganshin wrote:

...

Hello Thomas,

Saturday, March 28, 2009, 12:34:05 PM, you wrote:

...
...
...
I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work.

what kind of problems you are solving?

...
Large GUI applications doing lots of 3D rendering.

and you have written GUI in FP style? with trees, d&d support and so on?

I haven't, I'm working on a different part of the app – Peter Verswyvelen has though. Bob

Bulat Ziganshin

5:52 a.m.

New subject: Re[8]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 12:41:50 PM, you wrote:

...

...
and you have written GUI in FP style? with trees, d&d support and so on?

...

I haven't, I'm working on a different part of the app √ Peter Verswyvelen has though.

:) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Thomas Davie

5:55 a.m.

New subject: Re[8]: One more 'do' pattern

On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote:

...

Hello Thomas,

Saturday, March 28, 2009, 12:41:50 PM, you wrote:

...
...
and you have written GUI in FP style? with trees, d&d support and so on?

...
I haven't, I'm working on a different part of the app √ Peter Verswyvelen has though.

:) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too

it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell

And we can't possibly have written our own GUI library as part of the project? As it happens, this library binds on to Gtk2Hs, but that's a trivially small amount of code, and even there very little uses do notation. Bob

Bulat Ziganshin

6:14 a.m.

New subject: Re[10]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 12:55:39 PM, you wrote:

...

And we can't possibly have written our own GUI library as part of the project?

*you* can. i cannot. instead, i write a lot of code that implements features lacking in gtk2hs generally, i have very opposite positions in Haskell community and outside it some peoples say that i shouldn't use haskell because FP doesn't provide serious advantages over Java. they tend to consider anyone using Haskell as scientist other people say that i shouldn't use haskell if my usage doesn't fall into their idea of how it should be used but i just work. i deliver program to my users and using haskell for some its parts decrease time-to-market. if haskell will improve its 'do' syntax, it will reduce my development costs even more. just for comparison - something like GADT or AT or generics, while cute by itself, cannot help me at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Wolfgang Jeltsch

7:37 a.m.

Am Samstag, 28. März 2009 11:14 schrieb Bulat Ziganshin:

...

something like GADT or AT or generics, while cute by itself, cannot help me at all

GADTs and ATs help me a lot. There are practical things (like Grapefruit’s record system) that I couldn’t or wouldn’t want to do without these language extensions. Best wishes, Wolfgang

Bulat Ziganshin

7:55 a.m.

New subject: Re[2]: One more 'do' pattern

Hello Wolfgang, Saturday, March 28, 2009, 2:37:09 PM, you wrote:

...

GADTs and ATs help me a lot. There are practical things (like Grapefruit’s record system) that I couldn’t or wouldn’t want to do without these language extensions.

but not for me. strange, but i don't argue against them just because i don't know how to use them ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Wolfgang Jeltsch

8:03 a.m.

Am Samstag, 28. März 2009 12:55 schrieb Bulat Ziganshin:

...

Hello Wolfgang,

Saturday, March 28, 2009, 2:37:09 PM, you wrote:

...
GADTs and ATs help me a lot. There are practical things (like Grapefruit’s record system) that I couldn’t or wouldn’t want to do without these language extensions.

but not for me. strange, but i don't argue against them just because i don't know how to use them ;)

I just wanted to mention that they are useful. I didn’t want to claim that you disagree with that view. Best wishes, Wolfgang

Wolfgang Jeltsch

7:35 a.m.

Am Samstag, 28. März 2009 10:55 schrieb Thomas Davie:

...

And we can't possibly have written our own GUI library as part of the project?

As it happens, this library binds on to Gtk2Hs, but that's a trivially small amount of code, and even there very little uses do notation.

And your library supports tree views in a functional way? I’d be interested to know how you do this. Best wishes, Wolfgang

Thomas Davie

6:04 a.m.

New subject: Re[8]: One more 'do' pattern

On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote:

...

Hello Thomas,

Saturday, March 28, 2009, 12:41:50 PM, you wrote:

...
...
and you have written GUI in FP style? with trees, d&d support and so on?

...
I haven't, I'm working on a different part of the app √ Peter Verswyvelen has though.

:) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too

it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell

To get back on topic though... Here's *why* I don't want these specific things I wouldn't use added to haskell: • The syntax gains very little over the nice consistent syntax we already have – all you do is move a symbol a little to the left. • For that small benefit we gain all these disadvantages • The language gets harder to parse • We gain more reserved words that we can't use in our programs • We gain more corner cases that can't be explained simply using the basic rules of how application works in Haskell • We gain a syntax that even more than previously indicates that things will be executed in order (which is a total lie) • We encourage people to write code unnecessarily in an imperative style Hope that helps clarify why I'm objecting to this. Bob

Bulat Ziganshin

6:21 a.m.

New subject: Re[10]: One more 'do' pattern

Hello Thomas, Saturday, March 28, 2009, 1:04:01 PM, you wrote:

...

To get back on topic though... Here's *why* I don't want these specific things I wouldn't use added to haskell:

...

• The syntax gains very little over the nice consistent syntax we already have – all you do is move a symbol a little to the left.

main problem with lack-of-syntax is that we write "variables" at right: action x y >>= \v -> do action x y $ \v -> do another problem is all those funny "$\->do" one need to write

...

• We encourage people to write code unnecessarily in an imperative style

i wonder at this argument. we make using 'do' simpler and this is bad thing? :) probably you should argue against invention monads at all - it's Wadler who added imperative features to this pure shine Haskell :D about syntax - i don't mean that i proposed something ideal i just want to figure out here one pattern of 'do' usage which i use quite often. imho, moving variables to the left would be good thing, exact syntax is a matter of debates -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jesse Tov

1:04 p.m.

Bulat Ziganshin wrote:

...

...
• The syntax gains very little over the nice consistent syntax we already have – all you do is move a symbol a little to the left.

action x y >>= \v -> do action x y $ \v -> do

One way to settle this kind of dispute would be a real macro system. Bulat could define and use the desired syntax without modifying the language definition in a way that would disturb others. Template Haskell is great for some things, but it's unsuitable and unsatisfying in a case like this. This is out of scope for Haskell', of course, but it's something the community should consider adding at some point. I've uploaded a package called preprocessor-tools[1] to Hackage that provides very quick-and-dirty syntax extension using a preprocessor. I used it to define a do-notation for parameterized monads, back before GHC supported that. At one point I used it to define syntax for a "continuation let", which binds the "result" of a CPS-style function [2]: clet P = E1 in E === E1 (\P -> E) I think this is what Bulat wants. (Bulat, if you want to try this, let me know and I'll try to resurrect the code.) Cheers, Jesse [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/preprocessor-tool... [2] It seems to generalize nicely: clet P1 = E1 ... Pn = En in E === E1 (\P1 -> ... -> En (\Pn -> E) ... ) === flip runCont id $ do P1 <- Cont E1 ... Pn <- Cont En return E

Wolfgang Jeltsch

7:33 a.m.

Am Samstag, 28. März 2009 10:52 schrieb Bulat Ziganshin:

...

and i think that no functional GUI library support trees too

The development version of Grapefruit already supports list views (and the derived concept of a set view) in a functional style. Tree views can be supported in a similar way. Best wishes, Wolfgang

Bulat Ziganshin

7:53 a.m.

New subject: Re[2]: One more 'do' pattern

Hello Wolfgang, Saturday, March 28, 2009, 2:33:46 PM, you wrote:

...

The development version of Grapefruit already supports list views (and the derived concept of a set view) in a functional style. Tree views can be supported in a similar way.

of course everything can be supported, but when you just need to do some work it's no more an argument than "everything may be implemented in Turing machine" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Conal Elliott

4:54 p.m.

Hi Bulat, Do you have examples of usefulness your sugar for monads besides the one? Since "do" sugar is notation for general monadic programming, I wouldn't want to see it made more complex for the sake of just one monad. - Conal On Sat, Mar 28, 2009 at 1:54 AM, Bulat Ziganshin wrote:

...

Hello haskell-prime,

as we know, the following code

action x y >>= \v -> do

can be shortened to following

v <- action x y

but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter:

for list $ \element -> do ...

or

bracket createDialog destroyDialog $ \dialog -> do ...

what about adding one more 'do' sugar that will allow to move variable name to the left, such as

for element in list do or with dialog in bracket createDialog destroyDialog do

or just

element <-- for list do dialog <-- bracket createDialog destroyDialog do

?

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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

Bulat Ziganshin

4:56 p.m.

New subject: Re[2]: One more 'do' pattern

Hello Conal, Saturday, March 28, 2009, 11:54:55 PM, you wrote: no, i don't use other monads at all

...

Do you have examples of usefulness your sugar for monads besides the one? Since "do" sugar is notation for general monadic programming, I wouldn't want to see it made more complex for the sake of just one monad.

- Conal

...

On Sat, Mar 28, 2009 at 1:54 AM, Bulat Ziganshin wrote: Hello haskell-prime,

as we know, the following code

action x y >>= \v -> do

can be shortened to following

v <- action x y

but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter:

for list $ \element -> do ...

or

bracket createDialog destroyDialog $ \dialog -> do ...

what about adding one more 'do' sugar that will allow to move variable name to the left, such as

for element in list do or with dialog in bracket createDialog destroyDialog do

or just

element <-- for list do dialog <-- bracket createDialog destroyDialog do

?

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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

...

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5897

Age (days ago)

5897

Last active (days ago)

List overview

Download

21 comments

5 participants

participants (5)

Bulat Ziganshin
Conal Elliott
Jesse Tov
Thomas Davie
Wolfgang Jeltsch