Gábor Lehel illissius@... writes:
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
On Mon, Feb 13, 2012 at 8:41 AM, John Meacham j...@repetae.net wrote:
On Mon, Feb 13, 2012 at 12:07 AM, AntC anthony_clay...@clear.net.nz wrote:
So the advantage of dot from that point of view is:
* dot already appears tightly-bound in qualified names
* dot is already a reserved operator,
so
On Sun, Feb 12, 2012 at 3:51 PM, Ben Millwood hask...@benmachine.co.uk wrote:
On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
On 02/11/2012 09:21 PM, Roman Leshchinskiy wrote:
On 12/02/2012, at 02:04, Greg Weber wrote:
I am sorry that I made the huge
On 12/02/2012, at 02:39, Greg Weber wrote:
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
On 12/02/2012, at 02:42, Isaac Dupree wrote:
Does it help your concern about breaking existing code to make sure this
proposal has a LANGUAGE flag? (-XDotSpaces or such)
(I'm guessing that helps somewhat but not very satisfactorily; the more
default and standard it becomes, the more often
On 12 February 2012 18:00, Evan Laforge qdun...@gmail.com wrote:
On Thu, Feb 9, 2012 at 6:11 PM, Greg Weber g...@gregweber.info 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
+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
On Sat, Feb 11, 2012 at 4:07 PM, Doug McIlroy d...@cs.dartmouth.edu 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
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
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
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
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
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
On 02/11/2012 09:21 PM, Roman Leshchinskiy 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.
-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
On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree
m...@isaac.cedarswampstudios.org 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
On Fri, Feb 10, 2012 at 04:37, Malcolm Wallace malcolm.wall...@me.comwrote:
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
+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
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
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
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
... 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.
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
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
24 matches
Mail list logo
