Monads aren't evil

[Ertugrul Soeylemez]

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 very sparingly and mostly in the context of
input/output.  Also usually monads are associated with the do-notation,
which makes them appear even more special, although there is really
nothing special about them.

I appeal to all experienced Haskell programmers, especially to tutorial
writers, to try to focus more on how monads are nothing special, when
talking to beginners.  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 combinator frontend to what you would do
manually without them:  passing state.


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/


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

[Neal Alexander-2]

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 very sparingly and mostly in the context of
> input/output.  Also usually monads are associated with the do-notation,
> which makes them appear even more special, although there is really
> nothing special about them.
>

Yea, i was the same way when i started learning Haskell. I understood
how Monads worked, and what the motivation was for them, but not why i
would want to restructure code to use them in specific instances.

"Why should i care about monads when i can use Arrows or (.)" was also a
factor.

Its kinda like getting advice from an adult as a child. You have no
particular reason to distrust the advice, but the value of it doesn't
set in until something happens to you first hand to verify it.

For me the turning point was writing some code that needed to handle
running code locally/remotely in a transparent manner.

Maybe having a list of real-world usage scenarios or exercises on the
wiki may help.

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

[Peter Verswyvelen-2]

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 calculus core. Or is it maybe because some people choose monads were the less linear applicative style could be used instead, so the choice of monads is not always appropriate.

Haskell is full of little hardcoded syntax extensions: list notation syntactic, list comprehensions, and even operator precedence that reduces the need for parentheses, etc...

Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written without the arrows syntax would be incomprehensible for the average programmer. But one could claim that this syntactic sugar hides what is really going on under the hood, so for newcomers these extensions might make it harder. It could also feel like a hack, a failure to keep things as simple as possible yet elegant.

Some people I talked with like that about the Scheme/ & LISP languages: the syntax remains ultimately close to the core, with very little hardcoded syntactic extensions. And when one wants to add syntactic extensions, one uses syntactic macros. 

I'm not sure what others feel about the hardcoded syntax extensions in Haskell...

Personally I'm not that much of a purist, I'm an old school hacker that mainly needs to get the job done. I like the syntax extensions in Haskell (and even C#/F# ;) because they let me write code shorter and clearer... 

On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqweuqy@...> wrote:

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 very sparingly and mostly in the context of
input/output.  Also usually monads are associated with the do-notation,
which makes them appear even more special, although there is really
nothing special about them.

Yea, i was the same way when i started learning Haskell. I understood how Monads worked, and what the motivation was for them, but not why i would want to restructure code to use them in specific instances.

"Why should i care about monads when i can use Arrows or (.)" was also a factor.

Its kinda like getting advice from an adult as a child. You have no particular reason to distrust the advice, but the value of it doesn't set in until something happens to you first hand to verify it.

For me the turning point was writing some code that needed to handle running code locally/remotely in a transparent manner.

Maybe having a list of real-world usage scenarios or exercises on the wiki may help.

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

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

[Ryan Ingram]

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 extension.

For example, "fail" is in the Monad class only because binding in "do"
needs to handle pattern-match failure.  But a better syntax extension
wouldn't tie "do" to Monad only; it would allow pattern match failure
to be handled by a separate class if needed, and allow additional
extensions to deal with other cases where the existing syntax isn't
quite good enough.  This is where lisp-style syntactic macros show
their real power.

I'd go to TH but there's no way to make TH transparent.  I almost wish
that do ... and similar notations would just call a TH function to
decode the expression!  Then, if I wanted a different decoding I could
just put a different "sugarDoNotation" function in scope.

On a related note, I hate the explosion of <*>, <$>, liftM, etc. when
working in monadic/applicative code. Often the code only typechecks
with these lifting operators present, so why am I explaining to the
compiler that I want it to use the applicative apply operator?  When
is strong typing going to help me write *less* code instead of *more*?
 We've solved the "type annotation" problem to my satisfaction via
inference, but there is still a lot of what I would call "source
annotation".

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 be nice if it was?

Of course this raises problems of order of evaluation, etc, but as
long as such things were well-defined, that seems fine.  If you want
finer control, you can always go back to more verbose syntax.  These
cases are dominated by the cases where you simply don't care!

This said, I don't want to sound overly negative; all of this pain is
*worth* the correctness guarantees that I get when writing in Haskell.
 I just wish I could get the same guarantees with less pain!

  -- ryan


2009/1/10 Peter Verswyvelen <bugfact@...>:

> 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 calculus core. Or is it maybe because some people
> choose monads were the less linear applicative style could be used instead,
> so the choice of monads is not always appropriate.
> Haskell is full of little hardcoded syntax extensions: list notation
> syntactic, list comprehensions, and even operator precedence that reduces
> the need for parentheses, etc...
>
> Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written
> without the arrows syntax would be incomprehensible for the average
> programmer. But one could claim that this syntactic sugar hides what is
> really going on under the hood, so for newcomers these extensions might make
> it harder. It could also feel like a hack, a failure to keep things as
> simple as possible yet elegant.
> Some people I talked with like that about the Scheme/ & LISP languages: the
> syntax remains ultimately close to the core, with very little hardcoded
> syntactic extensions. And when one wants to add syntactic extensions, one
> uses syntactic macros.
> I'm not sure what others feel about the hardcoded syntax extensions in
> Haskell...
>
> Personally I'm not that much of a purist, I'm an old school hacker that
> mainly needs to get the job done. I like the syntax extensions in Haskell
> (and even C#/F# ;) because they let me write code shorter and clearer...
> On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqweuqy@...>
> wrote:
>>
>> 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 very sparingly and mostly in the context of
>>> input/output.  Also usually monads are associated with the do-notation,
>>> which makes them appear even more special, although there is really
>>> nothing special about them.
>>>
>>
>> Yea, i was the same way when i started learning Haskell. I understood how
>> Monads worked, and what the motivation was for them, but not why i would
>> want to restructure code to use them in specific instances.
>>
>> "Why should i care about monads when i can use Arrows or (.)" was also a
>> factor.
>>
>> Its kinda like getting advice from an adult as a child. You have no
>> particular reason to distrust the advice, but the value of it doesn't set in
>> until something happens to you first hand to verify it.
>>
>> For me the turning point was writing some code that needed to handle
>> running code locally/remotely in a transparent manner.
>>
>> Maybe having a list of real-world usage scenarios or exercises on the wiki
>> may help.
>>
>> ______________________________ _________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@...
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

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

[Peter Verswyvelen-2]

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 be nice if it was?

Yes, all that lifting is something that takes away lot of the beauty and simplicity of Haskell, but as far as my limited knowledge goes, I don't think this problem is easily solved :)

Anyway, for your particular example, for newbies I guess the clearest would be:

h0 x = [ fx+gx | fx <- f x, gx <- g x ]

since one must recognize that a list monad exists and what it does...

Now, for binary operators, Thomas Davie made a nice pair of combinators on Hackage (InfixApplicative) that would allow this to become:

h3 x = f x <^(+)^> g x

But in general, I guess you have a good point...

 

Of course this raises problems of order of evaluation, etc, but as
long as such things were well-defined, that seems fine.  If you want
finer control, you can always go back to more verbose syntax.  These
cases are dominated by the cases where you simply don't care!

This said, I don't want to sound overly negative; all of this pain is
*worth* the correctness guarantees that I get when writing in Haskell.
 I just wish I could get the same guarantees with less pain!

 -- ryan


2009/1/10 Peter Verswyvelen < bugfact@...>:

> 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 calculus core. Or is it maybe because some people
> choose monads were the less linear applicative style could be used instead,
> so the choice of monads is not always appropriate.
> Haskell is full of little hardcoded syntax extensions: list notation
> syntactic, list comprehensions, and even operator precedence that reduces
> the need for parentheses, etc...
>
> Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written
> without the arrows syntax would be incomprehensible for the average
> programmer. But one could claim that this syntactic sugar hides what is
> really going on under the hood, so for newcomers these extensions might make
> it harder. It could also feel like a hack, a failure to keep things as
> simple as possible yet elegant.
> Some people I talked with like that about the Scheme/ & LISP languages: the
> syntax remains ultimately close to the core, with very little hardcoded
> syntactic extensions. And when one wants to add syntactic extensions, one
> uses syntactic macros.
> I'm not sure what others feel about the hardcoded syntax extensions in
> Haskell...
>
> Personally I'm not that much of a purist, I'm an old school hacker that
> mainly needs to get the job done. I like the syntax extensions in Haskell
> (and even C#/F# ;) because they let me write code shorter and clearer...
> On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqweuqy@...>
> wrote:
>>
>> 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 very sparingly and mostly in the context of
>>> input/output.  Also usually monads are associated with the do-notation,
>>> which makes them appear even more special, although there is really
>>> nothing special about them.
>>>
>>
>> Yea, i was the same way when i started learning Haskell. I understood how
>> Monads worked, and what the motivation was for them, but not why i would
>> want to restructure code to use them in specific instances.
>>
>> "Why should i care about monads when i can use Arrows or (.)" was also a
>> factor.
>>
>> Its kinda like getting advice from an adult as a child. You have no
>> particular reason to distrust the advice, but the value of it doesn't set in
>> until something happens to you first hand to verify it.
>>
>> For me the turning point was writing some code that needed to handle
>> running code locally/remotely in a transparent manner.
>>
>> Maybe having a list of real-world usage scenarios or exercises on the wiki
>> may help.
>>
>> ______________________________ _________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@...
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

> _______________________________________________

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

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

[Brandon S. Allbery KF8NH]

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] allbery@...

system administrator [openafs,heimdal,too many hats] allbery@...

electrical and computer engineering, carnegie mellon university    KF8NH

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

[Andrew Wagner]

Holy concatenated operators, Batman!

Is that an operator or Batman?

(yes, I know, 3 operators)

-- 

brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@...

system administrator [openafs,heimdal,too many hats] allbery@...

electrical and computer engineering, carnegie mellon university    KF8NH

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

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

[Henning Thielemann-4]

Peter Verswyvelen schrieb:

> 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 calculus core. Or is it maybe because
> some people choose monads were the less linear applicative style could
> be used instead, so the choice of monads is not always appropriate.
>
> Haskell is full of little hardcoded syntax extensions: list notation
> syntactic, list comprehensions, and even operator precedence that
> reduces the need for parentheses, etc...

http://www.haskell.org/haskellwiki/Syntactic_sugar/Cons

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

[Henning Thielemann-4]

Peter Verswyvelen schrieb:

> Now, for binary operators, Thomas Davie made a nice pair of combinators
> on Hackage (InfixApplicative) that would allow this to become:
>
> h3 x = f x <^(+)^> g x

http://www.haskell.org/haskellwiki/Infix_expressions

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

[Heinrich Apfelmus]

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 combinator frontend to what you would do
> manually without them:  passing state.

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 patterns to "get the job done". But do you really need to
pass state around? Or is there a more elegant solution, an abstraction
that makes everything fall into place automatically? Passing state is a
valid implementation tool, but it's not a design principle.


A good example is probably the HGL (Haskell Graphics Library), a small
vector graphics library which once shipped with Hugs. The core is the type

  Graphic

which represents a drawing and whose semantics are roughly

  Graphic = Pixel -> Color

There are primitive graphics like

  empty   :: Graphic
  polygon :: [Point] -> Graphic

and you can combine graphics by laying them on top of each other

  over    :: Graphic -> Graphic -> Graphic

This is an elegant and pure interface for describing graphics.

After having constructed a graphic, you'll also want to draw it on
screen, which can be done with the function

  drawInWindow :: Graphic -> Window -> IO ()

This function is in the IO monad because it has the side-effect of
changing the current window contents. But just because drawing on a
screen involves IO does not mean that using it for describing graphics
is a good idea. However, using IO for *implementing* the graphics type
is fine

  type Graphics = Window -> IO ()

  empty          = \w -> return ()
  polygon (p:ps) = \w -> moveTo p w >> mapM_ (\p -> lineTo p w) ps
  over g1 g2     = \w -> g1 w >> g2 w
  drawInWindow   = id


Consciously excluding monads and restricting the design space to pure
functions is the basic tool of thought for finding such elegant
abstractions. As Paul Hudak said in his message "A regressive view of
support for imperative programming in Haskell"

   In my opinion one of the key principles in the design of Haskell has
   been the insistence on purity. It is arguably what led the Haskell
   designers to "discover" the monadic solution to IO, and is more
   generally what inspired many researchers to "discover" purely
   functional solutions to many seemingly imperative problems.

   http://article.gmane.org/gmane.comp.lang.haskell.cafe/27214

The philosophy of Haskell is that searching for purely functional
solution is well worth it.


Regards,
H. Apfelmus

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

[Ertugrul Soeylemez]

"Apfelmus, Heinrich" <apfelmus@...> 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 combinator frontend to what you would do manually
> > without them:  passing state.
>
> 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 patterns to "get the job done".  [...]

Often, the monadic solution _is_ the elegant solution.  Please don't
confuse monads with impure operations.  I use the monadic properties of
lists, often together with monad transformers, to find elegant
solutions.  As long as you're not abusing monads to program
imperatively, I think, they are an excellent and elegant structure.

I said that 90% of my code is monadic, not that 90% of it is in IO.  I
do use state monads where there is no more elegant solution than passing
state around.  It's simply that:  you have a structure, which you modify
continuously in a complex fashion, such as a neural network or an
automaton.  Monads are the way to go here, unless you want to do
research and find a better way to express this.

Personally I prefer this:

  somethingWithRandomsM :: (Monad m, Random a) => m a -> Something a

over these:

  somethingWithRandoms1 :: [a] -> Something a
  somethingWithRandoms2 :: RandomGen g => g -> Something a

Also I use monads a lot for displaying progress:

  lengthyComputation :: Monad m => (Progress -> m ()) -> m Result


> Consciously excluding monads and restricting the design space to pure
> functions is the basic tool of thought for finding such elegant
> abstractions. [...]

You don't need to exclude monads to restrict the design space to pure
functions.  Everything except IO and ST (and some related monads) is
pure.  As said, often monads _are_ the elegant solutions.  Just look at
parser monads.


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/


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

[Ertugrul Soeylemez]

Ertugrul Soeylemez <es@...> 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 = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/


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

[Jason Dusek]

  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 <allbery@...>:

> 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] allbery@...
> system administrator [openafs,heimdal,too many hats] allbery@...
> electrical and computer engineering, carnegie mellon university    KF8NH
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

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

[minh thu]

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 Data type name...

Cheers,
Thu

2009/1/11 Jason Dusek <jason.dusek@...>:

>  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 competitiveI
>  vis-a-vis LOLCode.
>
> --
> Jason Dusek
>
>
>
> 2009/1/10 Brandon S. Allbery KF8NH <allbery@...>:
>> 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] allbery@...
>> system administrator [openafs,heimdal,too many hats] allbery@...
>> electrical and computer engineering, carnegie mellon university    KF8NH
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@...
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

[Martijn van Steenbergen-2]

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
> C++ could be a Data type name...

No, operators have to consist entirely of punctuation, and functions
entirely of alphanumerical characters.

If what you said were the case, then x+y would be an identifier instead
of the sum of x and y.

Kind regards,

Martijn.

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

[minh thu]

2009/1/11 Martijn van Steenbergen <martijn@...>:

> 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
>> C++ could be a Data type name...
>
> No, operators have to consist entirely of punctuation, and functions
> entirely of alphanumerical characters.
>
> If what you said were the case, then x+y would be an identifier instead of
> the sum of x and y.

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)...

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

[Miguel Mitrofanov]

> 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           as           x + (y * z) + t

and

x + y  *  z + t       as           (x + y) * (z + t)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Bulat Ziganshin-2]

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                            mailto:Bulat.Ziganshin@...

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

[Lennart Augustsson]

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
<martijn@...> wrote:

> 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
>> C++ could be a Data type name...
>
> No, operators have to consist entirely of punctuation, and functions
> entirely of alphanumerical characters.
>
> If what you said were the case, then x+y would be an identifier instead of
> the sum of x and y.
>
> Kind regards,
>
> Martijn.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

[Martijn van Steenbergen-2]

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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe