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 sa
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
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
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 extens
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
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 yo
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
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
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.
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
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
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
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
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 sup
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?
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 re
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?
L
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,
Bulatm
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
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 t
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
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 $ \dial
22 matches
Mail list logo
