Well Iavor likes it. (see 2 below)

Anyway, you know I'm really puzzled with the question of how to spend time.

Maybe you can help me.

In any case, it's such a lucky thing to have some to spend.

Toshia and I are watching season 4 of Game of Thrones.  I'm so addicted.

I'm also addicted to speed chess in the same way. (I am ralf_ben_h at
chess.com)

I think that we have some structure in our minds, in our brains or our
spines or our hearts say, and any story or game illuminates and awakens
this structure.  The addictive feeling or attachment is a fascination with
this part of ourselves and a willingness to experience it.

You wrote me a note about music recently.  How are you feeling about music
today?

Best,
Ralph

On Sat, Jul 9, 2016 at 2:36 AM, <glasgow-haskell-users-requ...@haskell.org>
wrote:

> Send Glasgow-haskell-users mailing list submissions to
>         glasgow-haskell-users@haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
> or, via email, send a message with subject or body 'help' to
>         glasgow-haskell-users-requ...@haskell.org
>
> You can reach the person managing the list at
>         glasgow-haskell-users-ow...@haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Glasgow-haskell-users digest..."
>
>
> Today's Topics:
>
>    1. layout was Re: Proposal: ArgumentDo (C Maeder)
>    2. Re: Proposal: ArgumentDo (Iavor Diatchki)
>    3. Re: Proposal: ArgumentDo (C Maeder)
>    4. Re: Proposal: ArgumentDo (Bardur Arantsson)
>    5. Re: Proposal: ArgumentDo (Henrik Nilsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Jul 2016 14:37:04 +0200
> From: C Maeder <chr.mae...@web.de>
> To: glasgow-haskell-users@haskell.org
> Subject: layout was Re: Proposal: ArgumentDo
> Message-ID: <577f9e70.5090...@web.de>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> the layout language options are hard to find (at least in the user
> guide). Therefore I try to give an overview here. The relevant options
> I've found by using ghc-7.10.3 with option --supported-languages are:
>
> NondecreasingIndentation
> DoAndIfThenElse
>
> RelaxedLayout
> AlternativeLayoutRule
> AlternativeLayoutRuleTransitional
>
> I ignore the last 3 options since these seem to be candidates for
> removal: https://ghc.haskell.org/trac/ghc/ticket/11359.
>
> The default option is NondecreasingIndentation, that is
>
>   do
>   x
>   do
>   y
>
> is legal and parsed as a single expression "do {x ; do y}". With
> -XNoNondecreasingIndentation one gets an "Empty 'do' block" for the
> second do (and this error would not change with ArgumentDo!).
>
> DoAndIfThenElse is not switched on by default and requires the keywords
> "then" and "else" to be further indented for an "if" within a "do".
>
> So I believe these options do not interfere with ArgumentDo, but maybe
> this should be discussed more and maybe mentioned on the wiki page.
>
> Surely a single space (inserted before x or removed before the second
> "do") makes a difference between one or two argument expressions in the
> example below.
>
> HTH Christian
>
> Am 08.07.2016 um 11:20 schrieb C Maeder:
> > Surely layout can bite you:
> >
> >   f
> >   do
> >   x
> >   do
> >   y
> >
> > and I'm having difficulties to find the documentation for the various
> > layout options.
> >
> > But this is no argument against this proposal!
> >
> > Improper use of white spaces can always be used to obfuscate code!
> > Style guides are important. Furthermore, a wrong/unintended parse tree
> > (due to layout) will - in many cases - result in a typing error.
> >
> > Christian
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Jul 2016 09:42:24 -0700
> From: Iavor Diatchki <iavor.diatc...@gmail.com>
> To: Aloïs Cochard <alois.coch...@gmail.com>
> Cc: GHC users <glasgow-haskell-users@haskell.org>, Henrik Nilsson
>         <henrik.nils...@nottingham.ac.uk>
> Subject: Re: Proposal: ArgumentDo
> Message-ID:
>         <CAGK9nuo93t=-
> g9fktdg37ie7eefww6p5w5goud3dmqkha8o...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> while  we are voting here, I kind of like this proposal, so +1 for me.
>
> I understand that some of the examples look strange to Haskell old-timers
> but, as Joachim points out, the behavior is very consistent.   Besides, the
> "Less Obvious Examples" were selected so that they are, well, less obvious.
>   The common use cases (as in ticket #10843) seem quite appealing, at least
> to me, and not at all confusing.  But, then, I also like the
> records-with-no-parens notation :-)
>
> -Iavor
>
>
>
> On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard <alois.coch...@gmail.com>
> wrote:
>
> > -1 for same reasons.
> >
> > On 8 July 2016 at 14:00, Henrik Nilsson <henrik.nils...@nottingham.ac.uk
> >
> > wrote:
> >
> >> Hi all,
> >>
> >> Joachim Breitner wrote:
> >>
> >> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
> >> > > I don't think so: https://ghc.haskell.org/trac/ghc
> >> > /wiki/ArgumentDo#Bl
> >> > [...]
> >> > Where is the outer set of parenthesis coming from?
> >> >
> >> > This is all not related to the ArgumentDo notation. Note that [...]
> >>
> >> The very fact that that experts can't easily agree on how a small
> >> Haskell fragment is parsed to me just confirms that Haskell already
> >> is a syntactically very cumbersome language.
> >>
> >> The present proposal just makes matters worse. For that reason
> >> alone, I don't find it compelling at all. (So -1 from me, then.)
> >>
> >> I will not repeat the many other strong arguments against that has been
> >> made. But I must say I don't find the use cases as documented
> >> on the associated web page compelling at all. Maybe there is a tacit
> >> desire to be able to pretend functions are keywords for various
> >> creative uses in supporting EDSLs and such. But for that to be truly
> >> useful, one need to support groups of related keywords. Something
> >> like Agda's mixfix syntax springs to mind. But this proposal does
> >> not come close, so the benefits are minimal and the drawbacks large.
> >>
> >> As a final point, the inherent asymmetry of the proposal (the
> >> last argument position is special as, for certain kinds of
> >> expressions, parentheses may be omitted there but not elsewhere)
> >> is also deeply unsettling.
> >>
> >> Best,
> >>
> >> /Henrik
> >>
> >> --
> >> Henrik Nilsson
> >> School of Computer Science
> >> The University of Nottingham
> >> n...@cs.nott.ac.uk
> >>
> >>
> >>
> >>
> >> This message and any attachment are intended solely for the addressee
> >> and may contain confidential information. If you have received this
> >> message in error, please send it back to me, and immediately delete it.
> >> Please do not use, copy or disclose the information contained in this
> >> message or in any attachment.  Any views or opinions expressed by the
> >> author of this email do not necessarily reflect the views of the
> >> University of Nottingham.
> >>
> >> This message has been checked for viruses but the contents of an
> >> attachment may still contain software viruses which could damage your
> >> computer system, you are advised to perform your own checks. Email
> >> communications with the University of Nottingham may be monitored as
> >> permitted by UK legislation.
> >>
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >>
> >
> >
> >
> > --
> > *Λ\oïs*
> > http://twitter.com/aloiscochard
> > http://github.com/aloiscochard
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160708/f6d53261/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 9 Jul 2016 09:09:17 +0200
> From: C Maeder <chr.mae...@web.de>
> To: Henrik Nilsson <henrik.nils...@nottingham.ac.uk>,
>         glasgow-haskell-users@haskell.org
> Subject: Re: Proposal: ArgumentDo
> Message-ID: <5780a31d.5080...@web.de>
> Content-Type: text/plain; charset=utf-8
>
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>  (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference (that the
> type checker will not detect)!
>
> Cheers Christian
>
> Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:
> > Hi all,
>
> [...]
>
> > As a final point, the inherent asymmetry of the proposal (the
> > last argument position is special as, for certain kinds of
> > expressions, parentheses may be omitted there but not elsewhere)
> > is also deeply unsettling.
> >
> > Best,
> >
> > /Henrik
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 9 Jul 2016 09:42:06 +0200
> From: Bardur Arantsson <s...@scientician.net>
> To: glasgow-haskell-users@haskell.org
> Subject: Re: Proposal: ArgumentDo
> Message-ID: <nlq9se$vem$1...@ger.gmane.org>
> Content-Type: text/plain; charset=utf-8
>
> On 07/09/2016 09:09 AM, C Maeder wrote:
> > The asymmetry that you mention is already apparent for (Haskell98) infix
> > expressions, i.e. when "composing" lambda- or if-expression:
> >
> >  (if c then f else g) . \ x -> h x
> >
> > Parentheses around the last argument of "." do not matter, but
> > parentheses around the first argument make a real difference (that the
> > type checker will not detect)!
> >
>
> What I'm reading here is essentially
>
>   "Parser already does non-obvious thing"
>       ===> "Adding more non-obvious things is fine!"
>
> This is simply bad reasoning, and I'm not sure why a number of people
> are saying it. Am I missing something?
>
> Regards,
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 09 Jul 2016 10:46:14 +0100
> From: Henrik Nilsson <henrik.nils...@nottingham.ac.uk>
> To: C Maeder <chr.mae...@web.de>,  Henrik Nilsson
>         <henrik.nils...@nottingham.ac.uk>,
> glasgow-haskell-users@haskell.org
> Subject: Re: Proposal: ArgumentDo
> Message-ID: <5780c7e6.6030...@nottingham.ac.uk>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi all,
>
> On 07/09/2016 08:09 AM, C Maeder wrote:
> > The asymmetry that you mention is already apparent for (Haskell98) infix
> > expressions, i.e. when "composing" lambda- or if-expression:
> >
> >   (if c then f else g) . \ x -> h x
> >
> > Parentheses around the last argument of "." do not matter, but
> > parentheses around the first argument make a real difference
>
> But that has to do with how grammatical ambiguity related to
> in this case "if" and "lambda" are resolved by letting
> the constructs extend as far as possible to the right.
>
> This the standard way of resolving that kind of ambiguity
> across a very wide range of programming languages and parsing
> tools (e.g. preferring shift over reduce in an LR parser).
> (And also in principle how lexical ambiguities are typically
> resolved, sometimes referred to as the "maximal munch rule".)
>
> In contrast, the present proposal suggests treating
> different argument positions in grammatically
> different ways (different non-terminals). As far as I know,
> that is unprecedented. And in any case, it manifestly
> complicates the grammar (more non-terminals) and as
> a consequence adds another grammatical hurdle to
> learning the language.
>
> I think we often tend to forget just how exotic
> Haskell syntax can be to the uninitiated. Which is
> the vast majority of the rest of the programmer world
> as well as beginners. Only the other week I gave a
> presentation to a group of highly skilled developers
> at a tech-savvy London-based company. The emphasis of
> the talk was not at all on Haskell as such, but small
> Haskell fragments did feature here and there, which I
> (naively) thought would be mostly self explanatory.
> Well, let's just say I was wrong.
>
> Now, we can't make Haskell syntax less exotic (not that I'd
> advocate that: I think basic Haskell syntax for the most part
> strikes a pretty good balance on a number of counts), but we can
> certainly avoid making it even more complicated and exotic.
> Which the present proposal would, in my opinion.
>
> Best,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> n...@cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
> ------------------------------
>
> End of Glasgow-haskell-users Digest, Vol 155, Issue 9
> *****************************************************
>
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Reply via email to