Re: [Haskell-cafe] accessible layout proposal?
On Sep 22, 2009, at 8:01 PM, Jimmy Hartzell wrote:
I am in love with this proposal: http://www.haskell.org/haskellwiki/Accessible_layout_proposal
I hadn't read it before. Now that I have, I really do not like it. "Syntactic sugar causes cancer of the semicolon" as Alan Perlis once said, and to my taste this proposal definitely counts as cancer of the semicolon. In effect, its purpose is to overload vertical white space.
Any time that you have something where you think you need this, it's likely that a better solution is to break what you are doing into smaller pieces.
Well, look at code like this: wrapParens str = concat [ "(", str, ")" ] (And yes, I realize you can do something like this with 'printf "(%s)" str'.) First off, there is a serious issue with the commas. You should at least be allowed to have a comma after the last element, a la Python. Otherwise, the last one is randomly special in this list, and in a format like this, I regularly edit code accidentally leaving off commas, yielding stuff like: concat [ "(", str, ")" -- (oops, no comma!) lineEnd -- forgot I needed this ] which (of course) results in a very confusing type error. Meanwhile, you have to format your code very awkwardly, as the closing bracket can't be in the left-most column, and, all in all, you have lots and lots of commas cluttering up your otherwise clean-looking layout. You get humans reading the code based off of the physical layout, while the computer is interpreting it based on the presence of commas, which the human mind will naturally filter in favor of the layout. And as to the "simplifying your code" idea: however "pure" your code is, you will regularly have to embed lists of things in it (ADTs, export lists, data from the domain). And unless you're claiming it is *almost always bad style to have code looking like (from the proposal): main = do a <- getChar bracket_ (enter a) (exit a) (do putChar a putStrLn "hello") then the same argument holds for $# (which I expect is the most controversial part of the proposal): the humans read the layout, the computers read the parentheses, and there are many opportunities for error. I mean, probably in this case the code could stand to be changed to: with a = bracket_ (enter a) (exit a) main = do a <- getChar with a $ do putChar a putStrLn "hello" But I would *still* rather have: with a = bracket_ $# enter a exit a Layout is easier to read than parentheses. In summary, I have to spend a good portion of my time coding Haskell dealing with the fact that I have a lot of {'s, ['s, and ,'s to keep track of, and they rarely fit on one line (records, ADTs, lists). I have to spend a significant amount of my coding time finagling the layout to look sensible, and I don't think anyone would claim that I just shouldn't use records or ADTs.
Am Mittwoch 23 September 2009 02:51:59 schrieb Jimmy Hartzell:
On Sep 22, 2009, at 8:01 PM, Jimmy Hartzell wrote:
I am in love with this proposal: http://www.haskell.org/haskellwiki/Accessible_layout_proposal (Richard O'Keefe:)
I hadn't read it before. Now that I have, I really do not like it. "Syntactic sugar causes cancer of the semicolon" as Alan Perlis once said, and to my taste this proposal definitely counts as cancer of the semicolon. In effect, its purpose is to overload vertical white space.
Any time that you have something where you think you need this, it's likely that a better solution is to break what you are doing into smaller pieces.
I don't like it either. I have not nearly a s strong feelings as Mr. O'Keefe, but to me it doesn't look right.
Well, look at code like this:
wrapParens str = concat [ "(", str, ")" ]
(And yes, I realize you can do something like this with 'printf "(%s)" str'.)
Or, what I do: concat [ "(" , str , ")" ] (of course, here I would just write '(' : str ++ ")"). I admit it looked odd for the first couple of hours, but now I find it nice, clean and systematic.
First off, there is a serious issue with the commas. You should at least be allowed to have a comma after the last element, a la Python. Otherwise, the last one is randomly special in this list, and in a format like this, I regularly edit code accidentally leaving off commas, yielding stuff like:
concat [ "(", str, ")" -- (oops, no comma!) lineEnd -- forgot I needed this ]
And that is avoided, because a missing comma leaps to the eye.
which (of course) results in a very confusing type error. Meanwhile, you have to format your code very awkwardly, as the closing bracket can't be in the left-most column,
Which is a good thing in my eyes.
In summary, I have to spend a good portion of my time coding Haskell dealing with the fact that I have a lot of {'s, ['s, and ,'s to keep track of, and they rarely fit on one line (records, ADTs, lists). I have to spend a significant amount of my coding time finagling the layout to look sensible, and I don't think anyone would claim that I just shouldn't use records or ADTs.
I see your point but remain not liking the proposal.
Daniel Fischer wrote:
Or, what I do:
concat [ "(" , str , ")" ]
This is a lot better, true, but it still takes a lot of typing, and the first element is now special-cased, preventing easy copy-and-paste (although, admittedly, much less opportunity for mistake). On a more philosophical level, the signals used by the humans still are different from the signals used by the computer, which leads me to suspect such a system could still cause confusion.
And that is avoided, because a missing comma leaps to the eye.
True. Drawing this much attention to syntax, however, is part of why I find it aesthetically displeasing.
Which is a good thing in my eyes.
Well, yes, but it means that when you lay it out the way I was proposing, you had two levels of indentation. With the way you're using, it's a lot cleaner.
I see your point but remain not liking the proposal.
Do you mean you see that there is a problem in the language that needs fixing, but you just don't like this fix? Would you be open to a modified version of the proposal? Is it an aesthetic objection, or more philosophical?
Am Mittwoch 23 September 2009 04:06:11 schrieb Jimmy Hartzell:
Daniel Fischer wrote:
Or, what I do:
concat [ "(" , str , ")" ]
This is a lot better, true, but it still takes a lot of typing, and the
Huh? Per line it's two keystrokes more than with the accessible layout proposal. That's not a lot.
first element is now special-cased, preventing easy copy-and-paste
Making it slightly harder. Copy-Paste-Cursor to beginning-delete-comma. No big deal. Besides, how often does one need to copy the beginning of one list into the middle of another?
(although, admittedly, much less opportunity for mistake). On a more philosophical level, the signals used by the humans still are different from the signals used by the computer, which leads me to suspect such a system could still cause confusion.
I don't think so. The dominant factor to the human eye (at least to mine) is the layout. The commas are rather unobtrusive and go almost unnoticed.
And that is avoided, because a missing comma leaps to the eye.
True. Drawing this much attention to syntax, however, is part of why I find it aesthetically displeasing.
To me, it doesn't draw attention to syntax, only to syntax errors. When each line has its comma at the beginning, all is fine. When one line lacks the comma, it looks different and only then spring the commas to attention. Of course, it may be different for you.
Which is a good thing in my eyes.
Well, yes, but it means that when you lay it out the way I was proposing, you had two levels of indentation. With the way you're using, it's a lot cleaner.
I see your point but remain not liking the proposal.
Do you mean you see that there is a problem in the language that needs fixing, but you just don't like this fix?
I don't consider it a problem in the language. For me it works fine as is. But I can understand that if
In summary, I have to spend a good portion of my time coding Haskell dealing with the fact that I have a lot of {'s, ['s, and ,'s to keep track of, and they rarely fit on one line (records, ADTs, lists). I have to spend a significant amount of my coding time finagling the layout to look sensible,
there is reason to desire something that would simplify the process.
Would you be open to a modified version of the proposal?
Maybe. I haven't formed an opinion yet.
Is it an aesthetic objection, or more philosophical?
On an aesthetic level, I find #( and #[ absolutely terrible. Opening a parenthesis (or bracket) and not closing it just screams "WRONG!!!" to me. On the philosophical side, I'm not fundamentally opposed to syntax sugar, but I think it should be added sparingly. I don't think there is sufficient reason to add this sugar, but if many argue that there is, I would accept such an addition (just, please don't use #( and #[).
On Wed, 23 Sep 2009 15:06:25 Daniel Fischer wrote:
Am Mittwoch 23 September 2009 04:06:11 schrieb Jimmy Hartzell:
Daniel Fischer wrote:
Or, what I do:
concat [ "(" , str , ")" ]
This is a lot better, true, but it still takes a lot of typing, and the
Huh? Per line it's two keystrokes more than with the accessible layout proposal. That's not a lot.
first element is now special-cased, preventing easy copy-and-paste
Making it slightly harder. Copy-Paste-Cursor to beginning-delete-comma. No big deal. Besides, how often does one need to copy the beginning of one list into the middle of another?
Or you could use: concat ( : "(" : str : ")" :[]) Though you do sometimes have to bracket an element that you wouldn't otherwise have to, eg concat ( : "(" : str : ('a':'b':[]) : ")" :[])
participants (3)
-
Daniel Fischer -
Daniel McAllansmith -
Jimmy Hartzell