Re: Proposal: require spaces around the dot operator
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 support). Apologies for taking the discussion off topic. I'm not arguing for or against dot (and postfix) as record selector. I'm not arguing whther or not we should support postfix record selector (whatever the syntax/symbol). But _if_ we want postfix, we need to be sure that it binds tighter than function apply. Some examples (from TDNR observations on 'something odd', and using `?' as postfix field symbol): map toUpper customer?lastName desugar to === map toUpper (lastName customer) m?lookup key === (lookup m) key No other operator binds tighter than even function apply. So I think the best way to show that is to disallow spaces around the symbol. It graphically appeals to the notion of a [name] composed of several [name]s. As one poster didn't quite put it. 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 AntC ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 we won't have to search for some other candidate (.) is not a reserved op, it is defined and redefinable like every other operator and has no special fixity rules. main = do let x . y = x + y print (3 . 8) prints 11 like you would expect. Oddly enough, I have occasionally wanted (.) to bind tighter than function application but still be composition. map toUpper.chr xs has a nice feel to me :) To that I say: let f = drop 1 . filter odd . take 30 in f xs -- :) -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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. 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 it tends to break code anyway.) -Isaac Anything is allowed to happen if you have a LANGUAGE flag, but we're discussing what ought to be standardised. I think existing code breaks is not a great argument since we can just compile it with Haskell98 (or 2010) switches, although updating code is going to be a nuisance. [...] On reflection I take this back, it would be a real nuisance to have to do this. The rest of what I said stands independently of that, of course. -1 to spaces around dot. I could be persuaded regarding spaces around all operators: a quick survey of code I write suggests minimal changes would be necessary. What about the comma, though? Spaces around that would be pretty unnatural; it's already not /quite/ a real operator, but I think that's a shame, and maybe it ought to be. So I'm not voting on that proposal yet, although my instinct is I don't like it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 or not to expand the usage of the dot in the *future*. We could decide on a completely different usage than record field selection. Then we will have broken a lot of code just to remove a tiny inconsistency from the language. That really doesn't sound like a good idea to me. 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. Personally, I would much prefer this. BTW, after looking through the relevant Wiki pages I think the proposal is actually underspecified. The TDNR page introduces a new lexeme for .var_id. This is quite easy to integrate into the grammar and to parse but it means that (f).(g) and (f. g) still both parse as function composition applied to f and g. The DotOperator page, however, seems to require that neither of these parse as function composition. But in that case, what does the grammar look like for '.'? More specifically, what does Text.Read.lex return for the two examples? Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 it tends to break code anyway.) I'm actually not sure why anyone would want to turn on the flag if all it does is render legal Haskell code invalid. I really doubt it would become widely used. So while it would address my concern in a sense, I don't really see the point of introducing it. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 usage of the unspaced dot as a record
field selector as shown in proposal #129.
I'm hoping the eventual resolution for the whole record thing doesn't
involve dots, rather, that it does but is using them for composition.
So I don't want to support something that will break hundreds of lines
of code (I often use dot without spaces) for the sake of maybe
supporting something I think there are better solutions to in the
first place!
What's more, if records use dot as composition then not only do we not
need to worry about breaking tons of code and what meaning to give to
(.f) and (f.) sections, but I'll use even more space-less dots, to
compose together record labels :)
I agree with this. In reading over this discussion, I have often
wondered how people seem to have forgotten that *to Haskell
programmers* the dot means composition. We shouldn't worry so much
about how Java programmers read Haskell code, because obviously,
syntax is not the biggest hurdle to their understanding it anyway. We
should be concerned with how the people who are using Haskell every
day read the dot.
Sure, dot is also in the syntax for module selection, but at least for
my part I find even that much painful. I specifically go out of my way
to avoid using module qualifiers whenever possible because it looks
like composition and makes expressions hard to read. I will append
abbreviations of the module name to identifiers if I think that they
will conflict with other exports in the same project. I would avoid
using records because of it, and where I couldn't do so, I would end
up writing wrapper functions around field selections just to avoid
using dots for something other than composition. That would be sad, I
think. Almost any other string of symbol characters would be less
painful. Composition is by a good margin my most used infix operator,
and should be pretty common, I think, in any functional programmer's
code. Not only that, but dot is a *good* notation for it. It's
visually quiet, and it's easy to type on every keyboard/terminal
combination in existence.
By comparison, record selection is a far less important operation and
can be given a less pretty name. Personally, just using a prefix
(named) function to select a field seems completely adequate to me,
but we could invent some other string of symbols for people who want
to write it infix. Or, just an idea, recordValue{fieldName} could
translate into whatever function is used to select the field,
mimicking construction syntax.
- Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
+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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 r...@cse.unsw.edu.auwrote: 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 r...@cse.unsw.edu.au 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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. 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. 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 it tends to break code anyway.) -Isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
-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 g...@gregweber.info 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 pumpkin...@gmail.com 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 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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
+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 allber...@gmail.com wrote: 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 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 pumpkin...@gmail.com 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 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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
... 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 g...@gregweber.info 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 pumpkin...@gmail.com 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 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 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
