On Mon, Feb 13, 2012 at 8:41 AM, John Meacham wrote:
> On Mon, Feb 13, 2012 at 12:07 AM, AntC 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 we won't have to search for some ot
On Mon, Feb 13, 2012 at 12:07 AM, AntC 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 we won't have to search for some other candidate
(.) is not a reserved op, it is defined and r
Gábor Lehel 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 support).
>
On 12 February 2012 18:00, Evan Laforge wrote:
> On Thu, Feb 9, 2012 at 6:11 PM, Greg Weber 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
On Thu, Feb 9, 2012 at 6:11 PM, Greg Weber 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.
I
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
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 wh
On Sun, Feb 12, 2012 at 3:51 PM, Ben Millwood wrote:
> On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree
> 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 mistake in referencing future possible
>>>
On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree
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 mistake in referencing future possible
>>> proposals. If this proposal passes, that has no bearing on whe
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.
Pl
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 *futu
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 d
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 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
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
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
On Sat, Feb 11, 2012 at 4:07 PM, Doug McIlroy 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
> rewr
> +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 h
+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 Allber
On Fri, Feb 10, 2012 at 04:37, Malcolm Wallace 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
On 02/10/2012 06:09 AM, Gábor Lehel wrote:
On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree
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 thi
On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree
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 detrime
-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 wor
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
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
> ... 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 langua
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
pre
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 c
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
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 wi
30 matches
Mail list logo
