tl;dr. Please a take a minute to express your thoughts on
GHC's development priorities via this survey [1].
Hello everyone,
The GHC developers want to ensure that we are working on problems that
of most importance to you, the Haskell community. To this end we are
surveying the community [
Hey Sergey,
Sorry for the delay - thanks for all your changes! A few other people
have stepped up. But we still need more help of course. :)
I'm incorporating your changes into the main Git repository as we
speak, and I greatly appreciate it! I'm also incorporating changes
from othe
Hello *,
For a while now, I've been wanting to do a facelift on the GHC
homepage, but among many other things it's been a low priority. I'd
like for people to help, so I've tried to get the ball rolling.
The webpages existed in a Darcs repository previously (which wasn'
Thank you very much everyone. I now have a version of yarr which compiles under
ghc 7.8.3. I have yet to do the conditional compilation hackery to support back
versions but then I can make a release.
What a great community :-)
Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.wordpre
I forgot to mention that `cpphs' can mimick gcc's cpp, with the flag
`-cpp'. In Agda we have
ghc-options: -pgmPcpphs -optP--cpp
Francesco
On 24 December 2014 at 10:50, Francesco Mazzoli wrote:
> You can specify the pre-processor in the `ghc-options' field in the
> cabal file, e.g.
>
>
You can specify the pre-processor in the `ghc-options' field in the
cabal file, e.g.
ghc-options: -pgmPcpphs
Francesco
On 23 December 2014 at 17:14, Brandon Allbery wrote:
> On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz
> wrote:
>>
>> How very clever of you and thank you very much. Ch
On Tue, Dec 23, 2014 at 11:10 AM, Dominic Steinitz
wrote:
> How very clever of you and thank you very much. Changing ‘ to 1 does fix
> the problem.
>
> I would have thought this would work
>
> cabal install --with-gcc=gcc-4.9
>
>
> But sadly I still got the same error.
>
I think that changes the
42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>
> Any help would be very gratefully received.
>
> > {-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
> > FunctionalDependencies #-}
> > {-# LANGUAGE FlexibleContexts #-}
> >
How very clever of you and thank you very much. Changing ‘ to 1 does fix the
problem.
I would have thought this would work
> cabal install --with-gcc=gcc-4.9
But sadly I still got the same error.
Do I need a special version of cpphs?
Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuc
On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz
wrote:
> To restate the problem: this is from code that has not been changed for 2
> years. I get
>
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>
I think I see the problem. Are you by any chance on a mach
t; years. I get
>
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>
> Any help would be very gratefully received.
>
> > {-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
> FunctionalDependencies #-}
> > {-#
Ok I have a cut down version of the problem and am cross posting to
glasgow-haskell-users.
To restate the problem: this is from code that has not been changed for 2
years. I get
> Examples.hs:42:42: Parse error in pattern: con
> Failed, modules loaded: none.
Any help would be very grat
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 24 April 2014 01:29
> *To:* glasgow-haskell-users@haskell.org; ghc-d...@haskell.org; Richard
> Eisenberg; Simon Peyton Jones
> *Subject:* Help with c
about the nominal/representational distinction.
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 24 April 2014 01:29
To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org; Richard Eisenberg;
Simon Peyton Jones
Subject: Help
I'd appreciate help with a cast-related Core Lint error I'm getting with a
GHC plugin I'm working on:
Argument value doesn't match argument type:
Fun type:
Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) =>
EP (Enc (Vec ('S 'Z) Bool)) ->
on to be
> nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the
> ability of GHC's type system.
>
> Of course, I would like to help you with a way forward -- let me know if
> there's a way I can.
>
> Richard
>
> On Apr 14, 2014, at 4:12
maybe. If that fails, I think you've gone beyond the ability of
GHC's type system.
Of course, I would like to help you with a way forward -- let me know if
there's a way I can.
Richard
On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote:
> Hi Richard,
>
> I'm w
inferred to require a nominal parameter, the newtype would expect a
>> representational coercion, not the nominal one you are passing. Check the
>> dump (using -ddump-tc) of the newtype axiom to be sure.
>>
>> Though putting a `Sub` on `` and changing the Refl constructor on
&
utting a `Sub` on `` and changing the Refl constructor on
> `` would work, you would then be violating an invariant of GHC's
> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp
> tc [])) ...`.
>
> In sum, here is the coercion I think you want:
>
o (Refl
> (TyConApp tc [])) ...`.
>
> In sum, here is the coercion I think you want:
>
> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R
>
> This is one of the problems with roles -- they are *very* fiddly within
> GHC, and it's hard for a non-expert in roles to
asIf[0] _R)))_R
This is one of the problems with roles -- they are *very* fiddly within GHC,
and it's hard for a non-expert in roles to get them right.
Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and
may be of help.
Let me know if I can help further!
Richard
April 2014 06:00
To: ghc-d...@haskell.org; glasgow-haskell-users@haskell.org
Subject: Help with coercion & roles?
I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and
running into trouble with coercions & roles. Error message from Core Lint:
Warning: In the ex
I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and
running into trouble with coercions & roles. Error message from Core Lint:
Warning: In the expression:
LambdaCCC.Lambda.lamvP#
@ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool)
@ (Simple.HasIf G
Hello all!
I'm extremely happy to report (thanks to invaluable help from Stephen) that
my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not
its llc or opt. With some other tweaks to Stephen's above patch[1], we now
have a perfectly working GHC-iOS on OS X
Hi all,
I tried this — building GHC HEAD configured to use the native code gen, and
then building the cross compiler using that, and got the same errors as
everything else thus far:
https://gist.github.com/lukexi/02366ed57171400b961a
10.9 Mavericks is likely coming out in less than a month, along
What if you build a copy of head with the native code gen. Then build the
cross compiler using head on head?
On Sunday, August 11, 2013, Luke Iannini wrote:
> And the truly final word for the moment : ) —
> I built a tool to partially automate the indentation workaround for LLVM
> 3.0 and it yiel
And the truly final word for the moment : ) —
I built a tool to partially automate the indentation workaround for LLVM
3.0 and it yields the same "co-processor offset out of range"/"unsupported
relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets
to integer-simple/GHC/Integer
OK! So just to summarize:
Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap)
on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein
layout-based code along with mixed-tabs-and-spaces code fails to parse
correctly, with issues in hundreds of files in the GHC HEAD
Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do
not.
On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote:
> Further investigation:
>
> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
> problem still occurred.
>
> The problem only occurs wit
Further investigation:
I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
problem still occurred.
The problem only occurs with LLVM 3.0.
It is not related to cross-compilation or Stephen's patches: I tested this
on multiple fresh clones with --with-gcc=clang.
LLVM 3.2, 3
The Travis folks have decided they want to support Haskell better (multiple
compiler versions):
https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378
(Yay!) They're asking for someone to help them up with setup scripts.
They mention their cookbook collection here:
askell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Philip K.F. Hölzenspies
| Sent: 06 March 2013 10:29
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Need help interpreting renamer trace output
|
| Erratum; Of course, I meant that I had expected the
Erratum; Of course, I meant that I had expected the different
occurrences of 'x' to have the same uniques. Similarly, the different
occurrences of 'y'. I did *not* expect 'x' and 'y' to have the same
uniques.
Ph.
On Wed, 2013-03-06 at 10:18 +0100, Philip K.F. Hölzenspies wrote:
> Dear GHC-ers,
Dear GHC-ers,
I'm looking into the inerts of the renamer and I'm trying to get a feel
for where things are bound. I thought it would be useful to have a look
at how the renamer works on something known, so I compiled the following
program (with HEAD):
class Foo x where
type FooTy x y
foo ::
I want to vote, too.
I am ok with all of
case of
\case
\of
\case of
For me single arguments are enough. We already have this restriction for 'case'
and I can work around it simply by wrapping arguments in pairs temporarily (cf.
curry $ \case ...).
I vote against LambdaIf, since
Good news everyone. LambdaCase and MultiWayIf are now in HEAD. Thanks
for participating in the final push!
On Thu, Jul 5, 2012 at 9:42 PM, Mikhail Vorozhtsov
wrote:
>
> Hi.
>
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac tic
Am Montag, den 16.07.2012, 21:26 +0300 schrieb Wolfgang Jeltsch:
> Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
> > Remember that there is a \ in arrow notation in addition to proc.
> > So one might expect any abbreviation for \x -> case x of {...}
> > to mean the same \ thing in
Am Freitag, den 13.07.2012, 13:40 +0100 schrieb Ross Paterson:
> Remember that there is a \ in arrow notation in addition to proc.
> So one might expect any abbreviation for \x -> case x of {...}
> to mean the same \ thing in arrow notation too.
I completely agree. I had forgotten about the \ in a
On Fri, Jul 13, 2012 at 9:12 PM, Gábor Lehel wrote:
> On Thu, Jul 12, 2012 at 7:38 PM, Cale Gibbard wrote:
> > case of { ... }
> >
> > looks much better to me than
> >
> > \case of { ... }
>
> I also completely agree, but I don't want my opinion to get in the way
> of progress.
I don't much ca
On Thu, Jul 12, 2012 at 7:38 PM, Cale Gibbard wrote:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
>
> case of { ... }
>
> looks much better to me than
>
> \case of { ... }
>
> and the fo
Am Freitag, den 13.07.2012, 06:57 -0700 schrieb Donn Cave:
> Quoth Cale Gibbard:
> > Personally I don't see why everyone appears to prefer the syntax with
> > \ in it over just the obvious case section syntax which was originally
> > proposed.
> >
> > case of { ... }
> ...
> > Does anyone else agr
Quoth Cale Gibbard:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
>
> case of { ... }
...
> Does anyone else agree?
Yes. I don't see this as an `anonymous function' in any special sense
On Fri, Jul 13, 2012 at 01:21:25PM +0100, Wolfgang Jeltsch wrote:
> I’m strongly opposed to the
>
> case of { ... }
>
> syntax, because there seems to be no natural arrow expression analog of
> it.
>
> A notation that starts with \ (like “\case”) can be carried over to
> arrow expressions by
Am Donnerstag, den 12.07.2012, 13:38 -0400 schrieb Cale Gibbard:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
>
> case of { ... }
>
> looks much better to me than
>
> \case of { ... }
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the tick
Mikhail Vorozhtsov writes:
> Hi.
>
> After 21 months of occasional arguing the lambda-case
> proposal(s) is in danger of being buried under its own trac
> ticket comments. We need fresh blood to finally reach an
> agreement on the syntax. Read the wiki page[1], take a look
> at the ticket[2], vot
On Thu, Jul 12, 2012 at 03:13:42PM -0400, Cale Gibbard wrote:
> There are of course already lots of ways to create functions which
> don't involve \
Well, I think it should be clear that we're talking here about
anonymous functions.
> We're not exactly talking about function definitions, so much
On 13/07/2012 3:08 AM, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a
On 2012-07-12 23:48, Bulat Ziganshin wrote:
another interesting feature may be ruby-style matching defined by
execution of special function `match` instead of pattern matching:
switch var of
1+1 -> print "var==2"
[5..10] -> print "var in [5..10]"
(>20) -> print "var>20"
where (va
Hello wagnerdm,
Thursday, July 5, 2012, 7:22:38 PM, you wrote:
>> After 21 months of occasional arguing the lambda-case proposal(s) is
this reminded me old joke about PL/I: camel is the horse created by committee
i propose to return back and summarize all the requirements we have in
this area.
There are of course already lots of ways to create functions which
don't involve \
I mentioned sections (like (+1) desugaring to (\x -> x + 1)) already,
and of course, one can partially apply or compose and transform other
functions without explicit lambdas.
We're not exactly talking about functi
On Thu, Jul 12, 2012 at 01:38:56PM -0400, Cale Gibbard wrote:
> Personally I don't see why everyone appears to prefer the syntax with
> \ in it over just the obvious case section syntax which was originally
> proposed.
I don't think that the 'case section syntax' is obvious, because I don't
see t
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as a simple extension of operator
sections to ano
On 07/12/2012 04:27 AM, Iavor Diatchki wrote:
Hello,
I am late to the discussion and this is not entirely on topic, for which
I apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
> case
> | p1 -> e1
> | p2 -> e2
> | ...
desugars to:
> case () of
Hello,
I am late to the discussion and this is not entirely on topic, for which I
apologize, but I like the multi-branch case syntax someone mentioned
earlier:
Writing:
> case
> | p1 -> e1
> | p2 -> e2
> | ...
desugars to:
> case () of
> _ | p1 -> e2
> | p2 -> e2
> | ...
-Iavor
On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch
wrote:
> If we use \case for functions, we should use proc case for arrows;
> if we use \of for functions, we should use proc of for arrows.
>
> By the way, is proc a layout herald already?
No, proc is not a layout herald. The normal pattern is t
Am Dienstag, den 10.07.2012, 06:53 + schrieb Simon Peyton-Jones:
> > I strongly favor a solution where lambda-case expressions start with \,
> > because this can be generalized to proc expressions from arrow syntax
> > simply by replacing the \ with proc.
>
> […]
>
> I think it's very helpfu
Am Dienstag, den 10.07.2012, 08:53 +0100 schrieb Simon Marlow:
> On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:
> > Would you still expect tuples for \case if you didn't see the way
> > `case x, y of ...` was implemented (or thought that it is a
> > primitive construct)?
>
> Yes, I still think it'
On 10/07/2012 07:33, Mikhail Vorozhtsov wrote:
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout cont
On 09/07/2012 17:32, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:49 PM, Simon Marlow wrote:
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
and respectively
\case
P1, P2 -> ...
P3, P4 -> ...
as sugar for
\x y -> case x, y of
P1, P2 -> ...
P3, P4 -> ...
That looks a bit strange to
> I think it's very helpful if lambdas start with a lambda, which to
> me suggests \case.
I'd be interested to hear that explained a little further. To me it isn't
obvious that `case of' is `a lambda', but it's obvious enough what it is
and how it works (or would work) - it's `case' with type a -
On 07/10/2012 01:53 PM, Simon Peyton-Jones wrote:
| I strongly favor a solution where lambda-case expressions start with \,
| because this can be generalized to proc expressions from arrow syntax
| simply by replacing the \ with proc.
|
| Take, for example, the following function definition:
|
|
| I strongly favor a solution where lambda-case expressions start with \,
| because this can be generalized to proc expressions from arrow syntax
| simply by replacing the \ with proc.
|
| Take, for example, the following function definition:
|
| f (Left x) = g x
| f (Right y) = h y
|
|
On 07/10/2012 01:09 AM, Bardur Arantsson wrote:
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a combinat
On Mon, Jul 09, 2012 at 07:22:30PM +0300, Wolfgang Jeltsch wrote:
> Although I wasn’t asked, I want to express my opinion. I think, the use
> of the comma is strange. When declaring functions with multiple
> arguments, we don’t have commas:
>
> f Nothing y = y
> f (Just x) y = x
>
> In l
On 07/09/2012 06:01 PM, Mikhail Vorozhtsov wrote:
> On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
>> On 09/07/12 14:44, Simon Marlow wrote:
>>> I now think '\' is too quiet to introduce a new layout context. The
>>> pressing
>>> need is really for a combination of '\' and 'case', that is
>>> s
On 07/09/2012 11:22 PM, Wolfgang Jeltsch wrote:
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:
Could you express your opinion on the case "comma sugar", i.e.
case x, y of
P1, P2 -> ...
P3, P4 -> ...
as sugar for
case (# x, y #) of
(# P1, P2 #) -> ...
(# P3,
Am Montag, den 09.07.2012, 10:20 -0600 schrieb Chris Smith:
> Right, it seems to me that there are basically three reasonable proposals
> here:
>
> 1. "\ of" with multiple arguments. This is consistent with existing
> layout, and seems like a nice generalization of lambda syntax.
> 2. "case of"
On 07/09/2012 09:49 PM, Simon Marlow wrote:
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, t
Am Montag, den 09.07.2012, 21:04 +0700 schrieb Mikhail Vorozhtsov:
> Could you express your opinion on the case "comma sugar", i.e.
>
> case x, y of
>P1, P2 -> ...
>P3, P4 -> ...
>
> as sugar for
>
> case (# x, y #) of
>(# P1, P2 #) -> ...
>(# P3, P4 #) -> ...
>
> and respective
Right, it seems to me that there are basically three reasonable proposals here:
1. "\ of" with multiple arguments. This is consistent with existing
layout, and seems like a nice generalization of lambda syntax.
2. "case of" with a single argument. This is consistent with existing
layout, and see
Am Samstag, den 07.07.2012, 00:08 -0400 schrieb Tyson Whitehead:
> I've thought some more about this and it seems to me that there are
> two ways people might intuitively think about doing grouping via
> indentation.
>
> 1 - the first item is on the same line and subsequent ones are lined
> up
On 07/09/2012 09:52 PM, Twan van Laarhoven wrote:
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The
pressing
need is really for a combination of '\' and 'case', that is
single-argument so
that we don't have to write parentheses. I think
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The pressing
need is really for a combination of '\' and 'case', that is single-argument so
that we don't have to write parentheses. I think '\case' does the job
perfectly. If you want a mult
On 09/07/2012 15:04, Mikhail Vorozhtsov wrote:
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are sin
Hi Simon.
On 07/09/2012 08:23 PM, Simon Marlow wrote:
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård
wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
versions):
1: Omission: "case of".
On 07/07/2012 16:07, Strake wrote:
On 07/07/2012, Jonas Almström Duregård wrote:
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument
versions):
1: Omission: "case of". There seems to be some support for this but it
was not i
On 07/07/2012 05:08, Tyson Whitehead wrote:
PS: To be fully precise, the modified layout decoder in 9.3 would be
L (:ts) i (m:ms) = ; : (L ts n (m:ms)) if m = n
= } : (L (:ts) n ms) if n < m
L (:ts) i ms = L ts n ms
L ({n}::ts) i ms = { : (
If we're voting
I think \of is all right, and multi-argument case could be handy,
which rules out using 'case of' for lambda case, because it's the
syntax for a 0-argument case:
case of
| guard1 -> ...
| guard2 -> ...
Then multi-argument lambda case could use the comma syntax
On July 7, 2012 00:08:26 Tyson Whitehead wrote:
> The very limited scope of this (i.e., it would only apply to lines that end
> with a grouping construct where the next line is indented further than that
> line) should also address Simon's concerns regarding things like
>
>f x y = x + y
>
On 07/07/2012, Jonas Almström Duregård wrote:
> Couldn't we use \\ for multi-case lambdas with layout?
>
> If not, these are my preferences in order (all are single argument
> versions):
> 1: Omission: "case of". There seems to be some support for this but it
> was not included in the summary.
> 2
Quoting Jonas Almström Duregård :
Couldn't we use \\ for multi-case lambdas with layout?
Actually, \\ is a valid (infix) function name... and the base library
includes one in Data.List. That name is copied in several other
container interfaces, as well.
~d
__
Couldn't we use \\ for multi-case lambdas with layout?
If not, these are my preferences in order (all are single argument versions):
1: Omission: "case of". There seems to be some support for this but it
was not included in the summary.
2: Omission with clarification: "\case of"
3: "\of" - but I
On July 6, 2012 11:49:23 Tyson Whitehead wrote:
> Currently it depends on the depth of this new level of indentation relative
> to all the groupings started on that line. I think most people would
> expect it to just apply to the last grouping though. That is
>
> where { f x = do {
> stmt1
>
Whoops, my earlier answer forgot to copy mailing lists... I would love to
see \of, but I really don't think this is important enough to make case
sometimes introduce layout and other times not. If it's going to obfuscate
the lexical syntax like that, I'd rather just stick with \x->case x of.
On Ju
On 05/07/2012, Mikhail Vorozhtsov wrote:
> Hi.
>
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac ticket comments. We need fresh
> blood to finally reach an agreement on the syntax. Read the wiki
> page[1], take a look at the tic
On July 6, 2012 05:25:15 Simon Marlow wrote:
> > Why not just let enclosed scopes be less indented than their outer ones?
Let me be entirely clear about what I was thinking about. The third case for
the layout mapping in Section 9.3 of the report is
L ({n}:ts) (m:ms) = { : (L ts (n:
On 05/07/2012 20:31, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read
Christopher Done writes:
> P.S. \if then … else …?
btw, http://www.haskell.org/haskellwiki/If-then-else
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Twan,
The 0-ary version you proposed actually works even nicer with \of.
foo'' = case () of
() | quux -> ...
| quaffle -> ...
| otherwise -> ...
Starting from the above legal haskell multi-way if, we can, switch to
foo' = case of
| quux -> ...
| quaffle -> ...
| otherwise -> .
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote:
Hi.
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the tick
On 07/06/2012 02:31 AM, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Re
Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into
work tomorrow.
My main point with that observation is it cleanly allows for multiple argument
\of without breaking the intuition you get from how of already works/looks or
requiring you to refactor subsequent lines, t
On 07/05/2012 10:22 PM, wagne...@seas.upenn.edu wrote:
Quoting Mikhail Vorozhtsov :
After 21 months of occasional arguing the lambda-case proposal(s) is
in danger of being buried under its own trac ticket comments. We need
fresh blood to finally reach an agreement on the syntax. Read the wiki
p
On 07/06/2012 05:47 AM, Donn Cave wrote:
The `multi-clause lambda' seems more elegant, if the syntactical
problems could be worked out. I mean, unnamed functions are thus
just like named functions, something that you'd probably think to
try just as soon as you needed the feature.
I don't unders
On 07/06/2012 04:33 AM, Twan van Laarhoven wrote:
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case
and of
to permit a , separated list of expressions so this becomes applicable
to the
usual case construct. A naked unparenthesized , i
The `multi-clause lambda' seems more elegant, if the syntactical
problems could be worked out. I mean, unnamed functions are thus
just like named functions, something that you'd probably think to
try just as soon as you needed the feature.
I don't understand the issues well enough with the layout
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case and of
to permit a , separated list of expressions so this becomes applicable to the
usual case construct. A naked unparenthesized , is illegal there currently as
well. That would effec
I really like the \of proposal!
It is a clean elision with \x -> case x of becoming \of
I still don't like it directly for multiple arguments.
One possible approach to multiple arguments is what we use for multi-argument
case/alt here in our little haskell-like language, Ermine, here at S&P
Ca
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac ticket comments. We need fresh
> blood to finally reach an agreement on the syntax. Read the wiki
> page[1], take a look at the ti
1 - 100 of 295 matches
Mail list logo
