"Apfelmus, Heinrich" wrote:
> [...] but this is very different from using a particular monad like
> the state monad and hoping that using it somehow gives an insight into
> the problem domain.
You're right, mostly. However, there are a lot of problems, where you
cannot provide any useful abstra
Ertugrul Soeylemez wrote:
> [...]
Thank you for your reply, I think I can refine my thoughts. And make
them much longer... ;)
The elegance I have in mind comes from abstraction, that is when a type
takes a meaning on its own, independent of its implementation. Let's
take the example of vector gr
On Tue, 2009-01-13 at 19:44 -0500, Dan Doel wrote:
> On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
> > > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM,
> > > then
> > > that will be a cogent argument. Until then, one might argue that it
> > > misses "the whole
On Tue, Jan 13, 2009 at 07:44:17PM -0500, Dan Doel wrote:
> On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
> > Surely PutM and Writer Put have almost the same performance?! (I am
> > worried if not -- if not, can you give an indication why?)
>
> The underlying monoid is Builder. The po
On Tue, 2009-01-13 at 19:19 -0500, Dan Doel wrote:
> On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
> > On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote:
> > > I have seen several libraries where all functions of a monad have the
> > >
> > >> monadic result (), e.g. Binary.Put and oth
On Tuesday 13 January 2009 7:27:10 pm Luke Palmer wrote:
> > When GHC starts optimizing (Writer Builder) as well as it optimizes PutM,
> > then
> > that will be a cogent argument. Until then, one might argue that it
> > misses "the whole point of Put".
>
> Well it can still serve as an optimization
On Tue, Jan 13, 2009 at 5:19 PM, Dan Doel wrote:
> On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
> > On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote:
> > > I have seen several libraries where all functions of a monad have the
> > >
> > >> monadic result (), e.g. Binary.Put and oth
On Tuesday 13 January 2009 5:51:09 pm Luke Palmer wrote:
> On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote:
> > I have seen several libraries where all functions of a monad have the
> >
> >> monadic result (), e.g. Binary.Put and other writing functions. This is
> >> a clear indicator, that th
On Tue, Jan 13, 2009 at 11:21 AM, Tim Newsham wrote:
> I have seen several libraries where all functions of a monad have the
>> monadic result (), e.g. Binary.Put and other writing functions. This is
>> a clear indicator, that the Monad instance is artificial and was only
>> chosen because of the
I have seen several libraries where all functions of a monad have the
monadic result (), e.g. Binary.Put and other writing functions. This is
a clear indicator, that the Monad instance is artificial and was only
chosen because of the 'do' notation.
Maybe that was the initial reason, but I've act
On Tue, Jan 13, 2009 at 10:16:32AM +, ChrisK wrote:
> Henning Thielemann wrote:
>> I have seen several libraries where all functions of a monad have the
>> monadic result (), e.g. Binary.Put and other writing functions. This is
>> a clear indicator, that the Monad instance is artificial and was
Henning Thielemann wrote:
I have seen several libraries where all functions of a monad have the
monadic result (), e.g. Binary.Put and other writing functions. This is
a clear indicator, that the Monad instance is artificial and was only
chosen because of the 'do' notation.
I completely disagre
Ertugrul Soeylemez schrieb:
> "Apfelmus, Heinrich" wrote:
>
>> The insistence on avoiding monads by experienced Haskellers, in
>> particular on avoiding the IO monad, is motivated by the quest for
>> elegance.
>>
>> The IO and other monads make it easy to fall back to imperative
>> programming pa
As a physicist, I think that programming, like any design in general, is all
about making as little use of brain resources as possible at the time of
solving problems and to transmit the solution to others. This is the reason
why it is pervasive in all kinds of engineering the concepts of modularit
Lennart Augustsson wrote:
Agda has made the choice that you can have (almost) any sequence of
characters in identifiers. It works fine, but forces you to use white
space (which I do anyway).
No _'s though, which is exactly what Jason was after. :-)
Still, Agda rocks.
Martijn.
___
Agda has made the choice that you can have (almost) any sequence of
characters in identifiers. It works fine, but forces you to use white
space (which I do anyway).
-- Lennart
On Sun, Jan 11, 2009 at 4:28 PM, Martijn van Steenbergen
wrote:
> minh thu wrote:
>>
>> I always thought that instead
Hello Miguel,
Sunday, January 11, 2009, 7:06:54 PM, you wrote:
> I believe it was Bulat Ziganshin who once proposed parsing
> x + y*z + t as x + (y * z) + t
> and
> x + y * z + t as (x + y) * (z + t)
x+y * z+t should be here
--
Best regards,
Bulat
Indeed but what's wrong in writing x + y (with additional spaces) ?
Having the possiblity to write for instance +blah instead of inventing
things such as $>* is neat in my opinion (in code or for
typesetting)...
I believe it was Bulat Ziganshin who once proposed parsing
x + y*z + t
2009/1/11 Martijn van Steenbergen :
> minh thu wrote:
>>
>> I always thought that instead of having two classes of characters, one
>> for variable (and function) names and the
>> other for operators, only the first charater of the identifier could
>> mean it's one or the others,
>> so *vec or +poin
minh thu wrote:
I always thought that instead of having two classes of characters, one
for variable (and function) names and the
other for operators, only the first charater of the identifier could
mean it's one or the others,
so *vec or +point would be valid operator names and thus >_> too. And
I always thought that instead of having two classes of characters, one
for variable (and function) names and the
other for operators, only the first charater of the identifier could
mean it's one or the others,
so *vec or +point would be valid operator names and thus >_> too. And
C++ could be a Dat
It is really too bad we can not define the operators
>_> ^_^ <_<
These are significant from an internationalization standpoint;
and they'd make the language so much more competitive
vis-a-vis LOLCode.
--
Jason Dusek
2009/1/10 Brandon S. Allbery KF8NH :
> On 2009 Jan 10, at 15:19
Ertugrul Soeylemez wrote:
> Personally I prefer this:
>
> somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a
Of course, there is something missing here:
somethingWithRandomsM :: (Monad m, Random a) => m a -> m (Something a)
Sorry.
Greets,
Ertugrul.
--
nightmare = unsaf
"Apfelmus, Heinrich" wrote:
> Ertugrul Soeylemez wrote:
>
> > Let me tell you that usually 90% of my code is monadic and there is
> > really nothing wrong with that. I use especially State monads and
> > StateT transformers very often, because they are convenient and are
> > just a clean combina
Holy concatenated operators, Batman!
Is that an operator or Batman?
> (yes, I know, 3 operators)
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carne
On 2009 Jan 10, at 15:19, Peter Verswyvelen wrote:
h3 x = f x <^(+)^> g x
Is that an operator or Batman?
(yes, I know, 3 operators)
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical an
>
> For example, which of these is easier to read?
>
> f,g :: Int -> [Int]
>
> h1 :: Int -> [Int]
> h1 x = do
>fx <- f x
>gx <- g x
>return (fx + gx)
>
> h2 :: Int -> [Int]
> h2 x = (+) <$> f x <*> g x
>
> h3 :: Int -> [Int]
> h3 x = f x + g x -- not legal, of course, but wouldn't it
My issue is that there seem to be many cases where the syntax
extension does *almost* what I want, but not quite. And there isn't
any method to extend it, so you are left with two choices:
(1) Go back to unsugared syntax
(2) Hack your technique into the constraints of the existing syntax exten
Related to this issue, I have a question here.
I might be wrong, but it seems to me that some Haskellers don't like
writing monads (with do notation) or arrows (with proc sugar) because of the
fact they have to abandon the typical applicative syntax, which is so close
to the beautiful lambda calc
Ertugrul Soeylemez wrote:
Hello fellow Haskellers,
When I read questions from Haskell beginners, it somehow seems like they
try to avoid monads and view them as a last resort, if there is no easy
non-monadic way. I'm really sure that the cause for this is that most
tutorials deal with monads ve
30 matches
Mail list logo
