Proposal: require spaces around the dot operator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: require spaces around the dot operator

Greg Weber
Similar to proposal #20, which wants to remove it, but immediately
less drastic, even though the long-term goal is the same.
This helps clear the way for the usage of the unspaced dot as a record
field selector as shown in proposal #129.

After this proposal shows clear signs of moving forward I will add a
proposal to support a unicode dot for function composition.
After that we can all have a lively discussion about how to fully
replace the ascii dot with an ascii alternative such as <~ or <<<
After that we can make the dot operator illegal by default.

This has already been discussed as part of a records solution on the
ghc-users mail list and documented here:
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Daniel Peebles
I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages.

Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition.

Thanks,
Dan

On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <[hidden email]> wrote:
Similar to proposal #20, which wants to remove it, but immediately
less drastic, even though the long-term goal is the same.
This helps clear the way for the usage of the unspaced dot as a record
field selector as shown in proposal #129.

After this proposal shows clear signs of moving forward I will add a
proposal to support a unicode dot for function composition.
After that we can all have a lively discussion about how to fully
replace the ascii dot with an ascii alternative such as <~ or <<<
After that we can make the dot operator illegal by default.

This has already been discussed as part of a records solution on the
ghc-users mail list and documented here:
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

John Meacham
There is also '~' which has no use in expressions right now.

I am still undecided on the utility of TLDR, bogarting already contested
syntax seems premature.

I question the value of looking too much like other languages, in some sense
it hurts us, new programmers are constantly trying to define classes
first thing because they have the same name as a somewhat related thing
from whatever language they are coming from.
Even though they are rarely the correct solution for anything you would
encounter in basic haskels programming.
I don't know whether using '.' will exacerbate this or not, but it is far from
clear that it is a good thing.

    John

On Thu, Feb 9, 2012 at 6:27 PM, Daniel Peebles <[hidden email]> wrote:

> I'm very happy to see all the work you're putting into the record
> discussion, but I'm struggling to see why people are fighting so hard to get
> the dot character in particular for field access. It seems like a huge
> amount of work and discussion for a tiny bit of syntactic convenience that
> we've only come to expect because of exposure to other very different
> languages.
>
> Is there some fundamental reason we couldn't settle for something like # (a
> valid operator, but we've already shown we're willing to throw that away in
> the MagicHash extension) or @ (only allowed in patterns for now)? Or we
> could even keep (#) as a valid operator and just have it mean category/lens
> composition.
>
> Thanks,
> Dan
>
>
> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <[hidden email]> wrote:
>>
>> Similar to proposal #20, which wants to remove it, but immediately
>> less drastic, even though the long-term goal is the same.
>> This helps clear the way for the usage of the unspaced dot as a record
>> field selector as shown in proposal #129.
>>
>> After this proposal shows clear signs of moving forward I will add a
>> proposal to support a unicode dot for function composition.
>> After that we can all have a lively discussion about how to fully
>> replace the ascii dot with an ascii alternative such as <~ or <<<
>> After that we can make the dot operator illegal by default.
>>
>> This has already been discussed as part of a records solution on the
>> ghc-users mail list and documented here:
>> http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Greg Weber
In reply to this post by Daniel Peebles
There are 2 compelling reasons I know of to prefer dot for record access
1) follows an almost universal convention in modern programming languages
2) is consistent with using the dot to select functions from module name-spaces

We can have a lot of fun bike-shedding about what operator we would
prefer were these constraints not present. Personally I wouldn't care.
However, I find either one of these 2 points reason enough to use the
dot for record field access, and even without a better record system
the second point is reason enough to not use dot for function
composition.

It is somewhat convenient to argue that it is too much work and
discussion for something one is discussing against. The only point
that should matter is how existing Haskell code is effected.

On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles <[hidden email]> wrote:

> I'm very happy to see all the work you're putting into the record
> discussion, but I'm struggling to see why people are fighting so hard to get
> the dot character in particular for field access. It seems like a huge
> amount of work and discussion for a tiny bit of syntactic convenience that
> we've only come to expect because of exposure to other very different
> languages.
>
> Is there some fundamental reason we couldn't settle for something like # (a
> valid operator, but we've already shown we're willing to throw that away in
> the MagicHash extension) or @ (only allowed in patterns for now)? Or we
> could even keep (#) as a valid operator and just have it mean category/lens
> composition.
>
> Thanks,
> Dan
>
> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <[hidden email]> wrote:
>>
>> Similar to proposal #20, which wants to remove it, but immediately
>> less drastic, even though the long-term goal is the same.
>> This helps clear the way for the usage of the unspaced dot as a record
>> field selector as shown in proposal #129.
>>
>> After this proposal shows clear signs of moving forward I will add a
>> proposal to support a unicode dot for function composition.
>> After that we can all have a lively discussion about how to fully
>> replace the ascii dot with an ascii alternative such as <~ or <<<
>> After that we can make the dot operator illegal by default.
>>
>> This has already been discussed as part of a records solution on the
>> ghc-users mail list and documented here:
>> http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

AntC
In reply to this post by Greg Weber
> ... I'm struggling to see why people
> are fighting so hard to get the dot character in
> particular for field access. It seems like a huge amount
> of work and discussion for a tiny bit of syntactic
> convenience that we've only come to expect because of
> exposure to other very different languages.

Dan/all,

I think yous should backtrack to SPJ's SORF and TDNR
proposals, and the Yesod/Reddit discussion that triggered
the latest 'Records in Haskell' threads.
http://hackage.haskell.org/trac/ghc/wiki/Records

SORF: "It is critical to support dot-notation."

TDNR: "Exploting the power of the dot"

TDNR: "a feature that has a _cultural_ connection to OO,
       but that turns out to be fully compatible with a
functional language."

TDNR: "I have deliberately used dot ..."
      "It's standard practice, and that counts for a lot."
      "Selecting a field from a record is a particularly
convenient special case, ..."
      "... is doing the same job as Haskell's existing
qualified names, ..."


I guess the 'clincher' for me is that if we're going to ask
SPJ to implement anything (and there's no-one else who's
capable) we'd better have very powerful reasons to go
against his so clearly expressed views.

Remember GHC/Haskell Prime is not run as a democracy, it's a
benevolent meritocracy.

We've probaly only got one shot: if we don't include dot
notation with whatever happens for 'Records in Haskell',
we'll probably never get dot notation. SPJ has made it clear
Records is not a priority. If it contues to be an area for
hot dispute, it'll just die a death (again).


I do, however, agree with you questioning the effort going
into surface syntax vs. deep semantics.  (The relative
effort is confirming Wadler's rule.)

Because what's not getting enough 'airtime' is how we
address even the "narrow issue: namespacing for record field
names."

What we are tending to get (apart from the hatchet-job on
the dot) is another bundle of half-baked suggestions for the
impossibily difficult "broad issue: first class record
types".

I'm working towards a proposal for the narrow issue. I'm
trying to make the changes to Haskell as minimal as
possible. So far, I've built a prototype in GHC v 7.2.1
(with many record-oriented extensions), which gives me hope
I'm mostly asking for syntactic sugar.

It's been somewhat helpful with the design to 'test the
water' through the discussion lists. It's also been
distracting. I've only had one response that was really,
really helpful and on-topic -- and that was from SPJ, who
(heck knows) is a very busy person.

I don't want the response to my proposal (if/when I get time
to write it up convincingly) to focus on the dot. Luckily,
under my design, the dot is very much syntactic sugar. (So
actually, it would be absurdly simple to implement, and even
simpler to leave out. That is, simple compared to
implementing the semantics.) I don't need it. I'm in two
minds whether even to mention it.


AntC



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

John Meacham
In reply to this post by Greg Weber
I mean, it is not worth worrying about the syntax until the extension has been
 implemented, used, and proven useful to begin with. Monads were in use
well before the 'do' notation. Shaking out what the base primitives that make
up a monad took a while to figure out.

Even discussing syntax feels a little like a garage band discussing what
the lighting of their  stage show will look like before they learned to play
their instruments.

If we can implement it and test it without breaking existing code, why
wouldn't we? It would mean more people can experiment with the
feature because they wouldn't have to modify existing code much. So
we will have more feedback and experience with how it interacts with
other aspects of the language.

    John

On Thu, Feb 9, 2012 at 6:41 PM, Greg Weber <[hidden email]> wrote:

> There are 2 compelling reasons I know of to prefer dot for record access
> 1) follows an almost universal convention in modern programming languages
> 2) is consistent with using the dot to select functions from module name-spaces
>
> We can have a lot of fun bike-shedding about what operator we would
> prefer were these constraints not present. Personally I wouldn't care.
> However, I find either one of these 2 points reason enough to use the
> dot for record field access, and even without a better record system
> the second point is reason enough to not use dot for function
> composition.
>
> It is somewhat convenient to argue that it is too much work and
> discussion for something one is discussing against. The only point
> that should matter is how existing Haskell code is effected.
>
> On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles <[hidden email]> wrote:
>> I'm very happy to see all the work you're putting into the record
>> discussion, but I'm struggling to see why people are fighting so hard to get
>> the dot character in particular for field access. It seems like a huge
>> amount of work and discussion for a tiny bit of syntactic convenience that
>> we've only come to expect because of exposure to other very different
>> languages.
>>
>> Is there some fundamental reason we couldn't settle for something like # (a
>> valid operator, but we've already shown we're willing to throw that away in
>> the MagicHash extension) or @ (only allowed in patterns for now)? Or we
>> could even keep (#) as a valid operator and just have it mean category/lens
>> composition.
>>
>> Thanks,
>> Dan
>>
>> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <[hidden email]> wrote:
>>>
>>> Similar to proposal #20, which wants to remove it, but immediately
>>> less drastic, even though the long-term goal is the same.
>>> This helps clear the way for the usage of the unspaced dot as a record
>>> field selector as shown in proposal #129.
>>>
>>> After this proposal shows clear signs of moving forward I will add a
>>> proposal to support a unicode dot for function composition.
>>> After that we can all have a lively discussion about how to fully
>>> replace the ascii dot with an ascii alternative such as <~ or <<<
>>> After that we can make the dot operator illegal by default.
>>>
>>> This has already been discussed as part of a records solution on the
>>> ghc-users mail list and documented here:
>>> http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
>>>
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>
>>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Isaac Dupree-3
In reply to this post by Greg Weber
I support requiring spaces around the dot operator, *even if* we don't
ever end up using it for anything else.

It helps a bit in mentally parsing code, so I try to write that way
anyway.  So I don't mind making this change.

This change helps us community-wise, having one less issue for us to
concurrently agonize about as a community while talking about records
(whether or not we decide to use dot, it makes the conversation less
complicated).

-Isaac

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Malcolm Wallace-2
In reply to this post by John Meacham
-1.

I agree with John.  There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially).

Regards,
    Malcolm


On 10 Feb 2012, at 03:14, John Meacham wrote:

> I mean, it is not worth worrying about the syntax until the extension has been
> implemented, used, and proven useful to begin with. Monads were in use
> well before the 'do' notation. Shaking out what the base primitives that make
> up a monad took a while to figure out.
>
> Even discussing syntax feels a little like a garage band discussing what
> the lighting of their  stage show will look like before they learned to play
> their instruments.
>
> If we can implement it and test it without breaking existing code, why
> wouldn't we? It would mean more people can experiment with the
> feature because they wouldn't have to modify existing code much. So
> we will have more feedback and experience with how it interacts with
> other aspects of the language.
>
>    John
>
> On Thu, Feb 9, 2012 at 6:41 PM, Greg Weber <[hidden email]> wrote:
>> There are 2 compelling reasons I know of to prefer dot for record access
>> 1) follows an almost universal convention in modern programming languages
>> 2) is consistent with using the dot to select functions from module name-spaces
>>
>> We can have a lot of fun bike-shedding about what operator we would
>> prefer were these constraints not present. Personally I wouldn't care.
>> However, I find either one of these 2 points reason enough to use the
>> dot for record field access, and even without a better record system
>> the second point is reason enough to not use dot for function
>> composition.
>>
>> It is somewhat convenient to argue that it is too much work and
>> discussion for something one is discussing against. The only point
>> that should matter is how existing Haskell code is effected.
>>
>> On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles <[hidden email]> wrote:
>>> I'm very happy to see all the work you're putting into the record
>>> discussion, but I'm struggling to see why people are fighting so hard to get
>>> the dot character in particular for field access. It seems like a huge
>>> amount of work and discussion for a tiny bit of syntactic convenience that
>>> we've only come to expect because of exposure to other very different
>>> languages.
>>>
>>> Is there some fundamental reason we couldn't settle for something like # (a
>>> valid operator, but we've already shown we're willing to throw that away in
>>> the MagicHash extension) or @ (only allowed in patterns for now)? Or we
>>> could even keep (#) as a valid operator and just have it mean category/lens
>>> composition.
>>>
>>> Thanks,
>>> Dan
>>>
>>> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <[hidden email]> wrote:
>>>>
>>>> Similar to proposal #20, which wants to remove it, but immediately
>>>> less drastic, even though the long-term goal is the same.
>>>> This helps clear the way for the usage of the unspaced dot as a record
>>>> field selector as shown in proposal #129.
>>>>
>>>> After this proposal shows clear signs of moving forward I will add a
>>>> proposal to support a unicode dot for function composition.
>>>> After that we can all have a lively discussion about how to fully
>>>> replace the ascii dot with an ascii alternative such as <~ or <<<
>>>> After that we can make the dot operator illegal by default.
>>>>
>>>> This has already been discussed as part of a records solution on the
>>>> ghc-users mail list and documented here:
>>>> http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
>>>>
>>>> _______________________________________________
>>>> Haskell-prime mailing list
>>>> [hidden email]
>>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>>
>>>
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-prime
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Gábor Lehel
In reply to this post by Isaac Dupree-3
On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree
<[hidden email]> wrote:
> I support requiring spaces around the dot operator, *even if* we don't ever
> end up using it for anything else.

+1.

I would support requiring spaces around _all_ operators. I can't
immediately think of any operator where it would be detrimental, at
least, albeit my memory is not the greatest. It would free up a lot of
syntax space, whatever we might end up using it for. (Obviously we
would need some kind of incremental phase-in plan.)

I think it's worth specifying (for the dot operator or for whichever)
that a space would be required between the operator and its argument,
but not between the operator and parentheses if it's used as a section
(i.e. (f .) and (.) would still be valid).

(FWIW, I don't support phasing out the dot operator completely in
favor of unicode dot.)

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Isaac Dupree-3
On 02/10/2012 06:09 AM, Gábor Lehel wrote:

> On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree
> <[hidden email]>  wrote:
>> I support requiring spaces around the dot operator, *even if* we don't ever
>> end up using it for anything else.
>
> +1.
>
> I would support requiring spaces around _all_ operators. I can't
> immediately think of any operator where it would be detrimental, at
> least, albeit my memory is not the greatest.

FWIW, it's pretty common to sometimes omit spaces around arithmetic
operators +, -, *.  This was common enough to derail the idea to make
negative integer literals be lexed ( "-", no space, numeric literal ).
So you'd have to fight that battle.

I think spaces around all operators sounds nice in a new language; I'm
not sure about Haskell.

-Isaac

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Brandon Allbery
In reply to this post by Malcolm Wallace-2
On Fri, Feb 10, 2012 at 04:37, Malcolm Wallace <[hidden email]> wrote:
I agree with John.  There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially).


I would claim this should have been done back when hierarchical modules were added.

More generally, it seems to me the Haskell spec has a number of places where potentially colliding syntactic elements are expected to be disambiguated by the compiler, with effects ranging from restricting future syntactic modifications (such as with the present arguments over (.)) to the now-removed impossible brace insertion semantics of Haskell98.    Cutting things close syntactically just because you can is perhaps not the best of ideas; in this case, we'd be adding spaces both syntactically and metaphorically (in terms of "expansion space" in the spec), which I suspect is a good idea in general.

(To provide an example not related to the records discussion, every so often the question comes up of providing proper support for character sets which don't have an upper/lowercase distinction, where currently you can't declare types --- or, less often noted, use module names from those csets.  Fixing this is likely to complicate parsing periods even more than record.field syntax would.)

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Svein Ove Aas-2

+1 to the idea of requiring spaces around all operators. It's just good style 

-1 to using dot for record fields, however. That's too likely to confuse someone, especially if we end up having something like lenses baked into the language. (Please, please...)

On Feb 10, 2012 7:19 PM, "Brandon Allbery" <[hidden email]> wrote:
On Fri, Feb 10, 2012 at 04:37, Malcolm Wallace <[hidden email]> wrote:
I agree with John.  There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially).


I would claim this should have been done back when hierarchical modules were added.

More generally, it seems to me the Haskell spec has a number of places where potentially colliding syntactic elements are expected to be disambiguated by the compiler, with effects ranging from restricting future syntactic modifications (such as with the present arguments over (.)) to the now-removed impossible brace insertion semantics of Haskell98.    Cutting things close syntactically just because you can is perhaps not the best of ideas; in this case, we'd be adding spaces both syntactically and metaphorically (in terms of "expansion space" in the spec), which I suspect is a good idea in general.

(To provide an example not related to the records discussion, every so often the question comes up of providing proper support for character sets which don't have an upper/lowercase distinction, where currently you can't declare types --- or, less often noted, use module names from those csets.  Fixing this is likely to complicate parsing periods even more than record.field syntax would.)

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Doug McIlroy
In reply to this post by Greg Weber
> +1 to the idea of requiring spaces around all operators.
> It's just good style

> Cutting things close syntactically just because you can is perhaps
> not the best of ideas

Haskell is mathematical both in substance and style.  I would
not lightly prohibit the use of spacing conventions that have proved
over centuries to aid in understanding syntactic strucure.

For example, this code fragment to define addition on lists
is instantly intelligible.

instance Num a => Num [a] where
        (f:fs) + (g:gs) = f+g : fs+gs

But the formula becomes merely an obscure procession of symbols when
rewritten with the operators set off by spaces:

        ( fs : gs ) + ( g : gs ) = f + g : fs + gs

And it becomes too long and too subtly modulated to take in at
a glance if more spacing is added to emphasize precedence:

        ( f : fs )  +  ( g : gs )   =   f + g   :   fs + gs

Doug McIlroy

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Gábor Lehel
On Sat, Feb 11, 2012 at 4:07 PM, Doug McIlroy <[hidden email]> wrote:

> For example, this code fragment to define addition on lists
> is instantly intelligible.
>
> instance Num a => Num [a] where
>        (f:fs) + (g:gs) = f+g : fs+gs
>
> But the formula becomes merely an obscure procession of symbols when
> rewritten with the operators set off by spaces:
>
>        ( fs : gs ) + ( g : gs ) = f + g : fs + gs

I wouldn't require them inside parentheses, but that's a very good
point: the list constructor in patterns is an example of an operator
where basically no one ever uses spaces.

>
> And it becomes too long and too subtly modulated to take in at
> a glance if more spacing is added to emphasize precedence:
>
>        ( f : fs )  +  ( g : gs )   =   f + g   :   fs + gs

I would rather write (f + g) : (fs + gs), but point taken.

In any case, while I would in theory support spaces around all
operators, modulo counterexamples such as those presented above, I'm
not proposing it and I don't think anyone is, so it's probably best to
stick to discussing spaces around (.) (which I also support).
Apologies for taking the discussion off topic.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Roman Leshchinskiy
In reply to this post by Greg Weber
On 10/02/2012, at 02:41, Greg Weber wrote:

> There are 2 compelling reasons I know of to prefer dot for record access
> 1) follows an almost universal convention in modern programming languages
> 2) is consistent with using the dot to select functions from module name-spaces

I don't understand what you mean by "consistent" in 2). The TDNR proposal quite explicitly says that X.f and (X).f mean very different things. This isn't consistent, IMO, it's actually exactly the same inconsistency we have now.

> We can have a lot of fun bike-shedding about what operator we would
> prefer were these constraints not present. Personally I wouldn't care.
> However, I find either one of these 2 points reason enough to use the
> dot for record field access, and even without a better record system
> the second point is reason enough to not use dot for function
> composition.
>
> It is somewhat convenient to argue that it is too much work and
> discussion for something one is discussing against. The only point
> that should matter is how existing Haskell code is effected.

Huge amounts of existing Haskell code are broken by this. To me, that should override all other considerations. If Haskell is to be seen as a real-world programming language, then breaking code in this way simply shouldn't be acceptable.

I also don't really understand why it makes sense to take clear, concise and well-established syntax away from a very frequently used language feature and use it for (at least in my experience) a less widely used language feature without an equally clear and concise alternative for the former. Isn't the net effect less readable code?

As an aside, could -> be used for field access? I don't think it introduces any ambiguities (although it's late and I'm probably mistaken) and there are well-known precedents in other programming languages.

Roman



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Nate Soares
I'm very +1 on using -> for field access, I think it's a nice compromise. I doubt there are ambiguities considering that arrow do-notation (http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/arrow-notation.html) managed to use "->" without trouble. One possible concern is stomping on the feet of arrow do-notation, but I'm not sure we care about ghc language extensions.

If -> was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with "." when used for module access.

Yes, this would add *another* operator that is different when there are no spaces around it, but I think that it's a better approach than breaking a ton of existing haskell code.

On Sat, Feb 11, 2012 at 5:02 PM, Roman Leshchinskiy <[hidden email]> wrote:
On 10/02/2012, at 02:41, Greg Weber wrote:

> There are 2 compelling reasons I know of to prefer dot for record access
> 1) follows an almost universal convention in modern programming languages
> 2) is consistent with using the dot to select functions from module name-spaces

I don't understand what you mean by "consistent" in 2). The TDNR proposal quite explicitly says that X.f and (X).f mean very different things. This isn't consistent, IMO, it's actually exactly the same inconsistency we have now.

> We can have a lot of fun bike-shedding about what operator we would
> prefer were these constraints not present. Personally I wouldn't care.
> However, I find either one of these 2 points reason enough to use the
> dot for record field access, and even without a better record system
> the second point is reason enough to not use dot for function
> composition.
>
> It is somewhat convenient to argue that it is too much work and
> discussion for something one is discussing against. The only point
> that should matter is how existing Haskell code is effected.

Huge amounts of existing Haskell code are broken by this. To me, that should override all other considerations. If Haskell is to be seen as a real-world programming language, then breaking code in this way simply shouldn't be acceptable.

I also don't really understand why it makes sense to take clear, concise and well-established syntax away from a very frequently used language feature and use it for (at least in my experience) a less widely used language feature without an equally clear and concise alternative for the former. Isn't the net effect less readable code?

As an aside, could -> be used for field access? I don't think it introduces any ambiguities (although it's late and I'm probably mistaken) and there are well-known precedents in other programming languages.

Roman



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Roman Leshchinskiy
On 12/02/2012, at 01:29, Nate Soares wrote:

> If -> was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with "." when used for module access.

I'm not spaces matter in this case, -> is a reserved token so we would just have expressions of the form expr -> field with no special lexical rules. BTW, if -> doesn't work for some reason then there is also => which AFAIK isn't used in expressions at all currently.

Roman



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Greg Weber
I am sorry that I made the huge mistake in referencing future possible
proposals. If this proposal passes, that has no bearing on whether the
other proposals would pass, it just makes them possible.

Please help me fix my error by stopping all discussions of future
proposals and focusing solely on the one at hand.

Thank you!

Greg Weber

On Sat, Feb 11, 2012 at 5:39 PM, Roman Leshchinskiy <[hidden email]> wrote:
> On 12/02/2012, at 01:29, Nate Soares wrote:
>
>> If -> was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with "." when used for module access.
>
> I'm not spaces matter in this case, -> is a reserved token so we would just have expressions of the form expr -> field with no special lexical rules. BTW, if -> doesn't work for some reason then there is also => which AFAIK isn't used in expressions at all currently.
>
> Roman
>
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Roman Leshchinskiy
On 12/02/2012, at 02:04, Greg Weber wrote:

> I am sorry that I made the huge mistake in referencing future possible
> proposals. If this proposal passes, that has no bearing on whether the
> other proposals would pass, it just makes them possible.
>
> Please help me fix my error by stopping all discussions of future
> proposals and focusing solely on the one at hand.

But if we don't consider those future proposals, then what is the justification for this one? It does break existing code so there must be some fairly compelling arguments for it. I don't think it can be considered in isolation.

Roman



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: require spaces around the dot operator

Greg Weber
This proposal stands on its own
* the dot operator is inconsistent with Module function selection.
* we are allowed the option of expanding the usage of the dot without
spaces if this proposal goes forward.

The point is that we will decide whether or not to expand the usage of
the dot in the *future*. We could decide on a completely different
usage than record field selection.

If this proposal is not compelling enough on its own we should merge
it with other proposals and discuss them together as a single new
concrete proposal.
Let me know if that doesn't make sense. I am unfamiliar with the
process for this mail-list and obviously led things in the wrong
direction.

On Sat, Feb 11, 2012 at 6:21 PM, Roman Leshchinskiy <[hidden email]> wrote:

> On 12/02/2012, at 02:04, Greg Weber wrote:
>
>> I am sorry that I made the huge mistake in referencing future possible
>> proposals. If this proposal passes, that has no bearing on whether the
>> other proposals would pass, it just makes them possible.
>>
>> Please help me fix my error by stopping all discussions of future
>> proposals and focusing solely on the one at hand.
>
> But if we don't consider those future proposals, then what is the justification for this one? It does break existing code so there must be some fairly compelling arguments for it. I don't think it can be considered in isolation.
>
> Roman
>
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
12