gmane.comp.lang.haskell.prime

Re: proposal for trailing comma and semicolon

Neil Sculthorpe — 2013-05-20T19:50:46

Same with me.  I like using them, but turning on a language extension
feels excessive.

Re: proposal for trailing comma and semicolon

Tillmann Rendel — 2013-05-18T15:23:07

That would go well together with allowing extra commas, because in 
explicit block syntax, we can have extra semicolons.

Ben Millwood wrote:

I fear that this is confusing, because so far, layout is always 
introduced by a keyword. But here, layout is introduced by an 
identifier. I suspect this is also what makes problems below for update 
syntax etc.


I feel that record (definition | matching | literals | update) should 
all use the same syntax.


What about list literals?

   items = new-keyword-here
     "red"
     "blue"
     "green"

Again, I don't see how that can work out without introducing a keyword. 
Maybe reusing "data" would work:

   items = data
     "red"
     "blue"
     "green"

:)

   Tillmann

Re: proposal for trailing comma and semicolon

Ben Millwood — 2013-05-18T14:21:37

I'm interested in this idea. We should make sure we think it through and 
there are no weird cases, but if it all works out I'd be in favour.

This looks a bit too much like a GADT to my eyes:

data Point = MkPoint
     x :: Rational
     y :: Rational

Maybe the recommended style would be:

data Point =
   MkPoint
     x :: Rational
     y :: Rational

But I suppose pattern-matching, update syntax and so forth would 
probably still have to use explicit braces and commas. That 
inconsistency is probably a bit unpleasant.

I'd say import and export lists at least are probably fine with a 
layout-based rule.

Re: proposal for trailing comma and semicolon

Heinrich Apfelmus — 2013-05-18T08:05:14

This is the style I am using for records and lists as well. Here an 
example from actual code

     data EventNetwork = EventNetwork
         { actuate :: IO ()
         , pause   :: IO ()
         }

These days, all my record definitions look like that.

Allowing a superfluous leading comma would be great, because that makes 
it easier to move around the first line.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

Re: proposal for trailing comma and semicolon

Roman Cheplyaka — 2013-05-17T19:48:54

I use them sometimes, but would do that much more if they didn't require
adding an extension.

Roman

* Edward Kmett <ekmett-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> [2013-05-17 15:24:27-0400]

Re: proposal for trailing comma and semicolon

Edward Kmett — 2013-05-17T19:24:27

I personally use tuple sections a fair bit, though admittedly mostly for
simple (,a) or (a,) cases.


On Fri, May 17, 2013 at 3:01 PM, Ian Lynagh <ian-97r1ndUNnnIyY3YROqfsYA< at >public.gmane.org> wrote:

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: proposal for trailing comma and semicolon

Ian Lynagh — 2013-05-17T19:01:29

Tuple sections could look like
    (True, _)
rather than
    (True,)

Does anyone know how common tuple sections are, incidentally? They've
been around since GHC 6.12, so it would be interesting to know if people
are actually using them.


Actually, you are already allowed an extra trailing comma in import and
export lists.


It happens occasionally, especially when simplifying code while
debugging.

Commenting out list items is much more common, though.

I'd be in favour of allowing a trailing or leading comma anywhere that
comma is used as a separator. TupleSections would need to be changed or
removed, though.


Thanks
Ian

Re: proposal for trailing comma and semicolon

Greg Weber — 2013-05-17T18:37:29

I think Tilmann's way is the right way (because it is very clear when a
comma is missing since they align, unlike trailing commas), although the
original proposal is the popular way. I would rather get rid of commas
altogether (make them optional actually) and just have a newline +
consistent indentation signal a new list item: coffee-script does that.


On Fri, May 17, 2013 at 11:23 AM, Tillmann Rendel <
rendel-jNDFPZUTrfTbB13WlS47k8u21/r88PR+s0AfqQuZ5sE< at >public.gmane.org> wrote:

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: proposal for trailing comma and semicolon

Tillmann Rendel — 2013-05-17T18:23:02

Hi,

Garrett Mitchener wrote:

(I don't think this is valid Haskell. The closing } and ] should be more 
indented).

I like to put commas at the beginning of lines, because there, I can 
make them line up and it is visually clear that they are all at the same 
nesting level. I like how the commas look a bit like bullet points. For 
example, I would write:

items =
   [ "red"
   , "blue"
   , "green"
   ]

Could we extend Garett's proposal to also allow prefixing the first 
element of a list with a comma, to support this style:

items = [
   , "red"
   , "blue"
   , "green"
   ]

Allowing an optional extra comma both at the beginning and at the end 
would allow programmers the choice where they want to put their commas.

   Tillmann

Re: proposal for trailing comma and semicolon

Edward Kmett — 2013-05-17T18:04:44

My main concern is its a really weird corner case for the grammar to
remember for tuple sections and it does have very weird grammar
specification issues.

I really have no objection to it for the other cases. It'd make export
lists cleaner, maybe a few other cases, but how often can you really say
you can meaningfully comment out one field of a tuple have have the
surrounding code make any sense?

-Edward


On Fri, May 17, 2013 at 12:35 PM, Bardur Arantsson <spam-g6Z8K4sVZMmXcCBPOl39Kg< at >public.gmane.org>wrote:

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: proposal for trailing comma and semicolon

Bardur Arantsson — 2013-05-17T16:35:33

Multiline tuples don't seem all that common, so +1 on that from me.

Re: proposal for trailing comma and semicolon

Johan Tibell — 2013-05-17T16:32:16

On Fri, May 17, 2013 at 9:17 AM, Garrett Mitchener <
garrett.mitchener-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


I've also thought about this issue and I agree with Garrett, allowing that
trailing comma (or semicolon) would help readability*. If it doesn't work
with tuples, perhaps we could at least do it with lists and records?

* It also hurts source control diffs a bit, as adding extra commas will
give diffs that suggest that one additional line was changed.

proposal for trailing comma and semicolon

Garrett Mitchener — 2013-05-17T16:17:17

There's a weird idiom that I see all the time in Haskell code where coders
put commas at the beginning of lines:

data Thing = Thing {
  x :: Int
  ,y :: Int
  ,z :: Int
  ,foo :: String
} ...

items = [
  "red"
  ,"blue"
  ,"green"
]

and it's pretty clear that the reason for this is that it's easier to
comment out the last item by prefixing --

items = [
  "red"
  ,"blue"
  -- ,"green"
]

instead of

items = [
  "red",
  "blue" -- ,
  -- "green"
]

The same sort of thing shows up with semicolons sometimes too

let {
 x = 1
 ;y = 2
 ;z = 3
} in

However, this punctuation-at-the-front just seems wrong.  It ultimately
comes from using , as a separator rather than a terminator in the syntax of
sequences.  But Python has this nifty quirk where you can leave a comma
after the last item in a sequence, so that the following is OK in Python
but not in Haskell:

items = [
  "red",
  "blue",
  -- "green"
]

Part of why Python does this is to allow room in the syntax for tuples with
a single item as in (1,)

There mig

Re: relaxing instance declarations

Ben Millwood — 2013-05-02T11:19:42

Maybe we need a better answer for the default method cycle problem? I 
had the following vague idea one day: don't allow default definitions in 
class members. Just use things along the lines of fmapDefault, or, say, 

subtractFromPlusNegate :: (n -> n -> n) -> (n -> n) -> n -> n -> n
subtractFromPlusNegate (+!) neg a b = a +! neg b

A bit clumsier but way more explicit: no more warning-silent infinite 
loops from code you didn't even write. The only drawback is the lack of 
the ability to introduce new class methods with default definitions. 
But! Here's my second idea: use RecordWildcards and NamedFieldPuns, 
allow pattern bindings instead of just simple variables in class 
instances, and do something like this:

      data MonoidInstance m = MkMonInst
        { mempty :: m
        , mappend :: m -> m -> m
        }

      monoidFromMconcat :: ([m] -> m) -> MonoidInstance m
      monoidFromMconcat mcat = MkMonInst
        { mconcat = mcat
        , mempty = mcat []
        , mappend x y = mcat [x,y]

RE: relaxing instance declarations

Sittampalam, Ganesh — 2013-05-02T08:10:37

Doug suggested this below:

 

“Capture can be prevented by declaring type signatures for local
variables.  The compiler might warn when such defensive
declarations are lacking.”

 

I think what Doug is proposing is that it be a warning *not* to include a type signature for any local declaration in an instance, and continue to be an error to provide a type signature for any class member implementation. That would mean that if you started warnings-free, a change in the type class that captured a local would always result in an error.

 

The downsides I see are that

(a)   it doesn’t seem very intuitive for the presence or absence of type signatures to signify whether something is local or not

(b)   GHC has a recent extension “InstanceSigs” that allows signatures to be given on class members

 

 

Overall I like the idea of regularizing the language and have wanted something like this myself in the past, but Edward’s objection feels significant to me.

 

 

From: haskell-prime-bounces-HC+Z4NTR

Re: Is it time to start deprecating FunDeps?

2013-05-02T07:14:25


First of all, on the top of other issues, I haven't actually shown an
implementation in the message on Haskell'. I posed this as a general
issue.

In special cases like below

    > class Sum2 a b c | a b -> c, a c -> b
    > instance Sum2 Z b b
    > instance (Sum2 a' b c') => Sum2 (S a') b (S c')

    > -- note that in the FunDeps, var a is not a target
    > -- so the instances discriminate on var a
I didn't doubt the translation would go through because there is a
case analysis on a. But the general case can be more complex. For
example,

class Sum2 a b c | a b -> c, a c -> b
instance Sum2 Z Z Z
instance Sum2 O Z O
instance Sum2 Z O O
instance Sum2 O O Z




I don't understand the remark. The code marked `correctly prohibited'
is in the comments. There are no claims were made about that code. If
you found that comment disturbing, please delete it. It won't affect the
the example: the types were improved in t11 but were not
improved in t21. Therefore, EC's are not just as good. Functional
dependencies s

Re: Is it time to start deprecating FunDeps?

Edward Kmett — 2013-05-02T00:00:29

Ultimately this is the wrong forum for this discussion as neither type
equalities nor functional dependencies are in Haskell' at this time.


On Wed, May 1, 2013 at 7:04 PM, AntC <anthony_clayden-oKK1aGe2n869koe0gwxAeg< at >public.gmane.org> wrote:

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Is it time to start deprecating FunDeps?

AntC — 2013-05-01T23:04:02


I'm still not sure you've 'got' it. The class has 2 FD's. Oleg put:


But you haven't captured the FD from {result, arg1} -> arg2.
In the TF example you first posted, you expressed that with an explicit 
equality constraint. (I won't repeat yours, because it wasn't to do with 
Peano Arith.)



No, not asking, but stating; and not talking about the intermediate 
language, but the surface language.

Could I respectfully suggest you re-read the OP.

Mobile support

Andrew Pennebaker — 2013-05-01T21:17:55

That would be cool!
_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Is it time to start deprecating FunDeps?

Edward Kmett — 2013-05-01T15:26:09

Er, what I meant was

class Foo s t a b | s -> a, t -> b, s b -> t, t a -> s

That is what I get for dashing it off off the cuff. =)

Then s determines some type argument for it, t determines its type
argument, but Using s and the other type argument I can determine the whole
containing type 't' and vice versa.

instance Foo (Identity a) (Identity b) a b



On Wed, May 1, 2013 at 7:02 AM, Ian Lynagh <ian-97r1ndUNnnIyY3YROqfsYA< at >public.gmane.org> wrote:

_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w< at >public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Haskell 2014

Ian Lynagh — 2013-05-01T13:40:04

Dear Haskellers,

We are pleased to announce that the Haskell 2014 committee has now
formed, and we would be delighted to receive your proposals for changes
to the language. Please see
    http://hackage.haskell.org/trac/haskell-prime/wiki/Process
for details on the proposal process.

The committee will meet 4 times a year, to consider proposals completed
before:
    * 1st August
    * 1st November
    * 1st February
    * 1st May
so if you have been meaning to put the finishing touches to a proposal,
then we would encourage you to do so by the end of July!

The source for the Haskell report will be updated as proposals are
accepted, but new versions of the standard will only be released once a
year, during January.

The Haskell 2014 committee is comprised of:

    * Carlos Camarão
    * Iavor Diatchki
    * Ian Lynagh (chair)
    * John Meacham
    * Neil Mitchell
    * Ganesh Sittampalam
    * David Terei
    * Bas van Dijk
    * Henk-Jan van Tuyl


Thanks
Ian (Haskell 2014 committee chair)