Hi, I often run into the following issue: I want to write a list of lengthy items like this mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ] With the current layout rules this is a parse error (at the closing bracket). Normally I avoid this by indenting everything one level more as in mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ] but I think this is a little ugly. Same issue comes up with parenthesized do-blocks, I would like to write when (condition met) (do first thing second thing ) So my wish is for a revised layout rule that allows closing brackets (of all sorts: ']', ')', '}') to be on the same indent level as the start of the definition/expression that contains the corresponding opening bracket. Cheers Ben
On Wed, 28 Mar 2007 22:21:08 +0200, you wrote:
I often run into the following issue: I want to write a list of lengthy items like this
mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ]
I suspect that I'm in a small minority, but I prefer this: mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three] primarily because horizontal real estate is generally cheaper than vertical real estate. Nested lists look like this: mylist = [[ item_1_1, item_1_2], [ item_2_1, item_2_2]] Another alternative: mylist = [ quite_lengthy_list_item_number_one , quite_lengthy_list_item_number_two , quite_lengthy_list_item_number_three ] which looks very weird but makes sense, in a twisted sort of way. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/
On 28/03/07, Steve Schafer
Another alternative:
mylist = [ quite_lengthy_list_item_number_one , quite_lengthy_list_item_number_two , quite_lengthy_list_item_number_three ]
I see this a lot. My personal preference is: mylist = [ foo, bar, baz, qux, quux, foo, bar, baz, qux ] -- -David House, dmhouse@gmail.com
On 3/28/07, Andrzej Jaworski
mylist = [ foo, bar, baz, qux, quux, foo, bar, baz, qux ]
Good direction. Perhaps you can also figure out how to replace the disturbing $ operator?
Why is it disturbing? Cheers, Tim -- Tim Chevalier * chevalier@alum.wellesley.edu * Often in error, never in doubt Confused? See http://catamorphism.org/transition.html
Perhaps you can also figure out how to replace the disturbing $ operator?
Why is it disturbing?
It is not that I am short on dollar or Eurofobic;-) It introduces sort of daub aesthetics to the code. Also for someone that puts strong emphases on notation signs should have some semiotic responsibility and shouldn't shout at you without having sufficient prominence. I wouldn't use this arguments with Perl programmers of course. Cheers -Andrzej
DavidA
I suggest << in place of $. For example: h x = f << g << x
I would feel better with : " |> " Ideally, redesigning Haskell syntax for 21st century should take more scientific course. But with know-how here still much lagging we can only tap on experience with symbol manipulation in mathematics. For instance: construction of formulas should store some dynamics supportive for the underlying thought process. So for example "f a b" springs up no association while "f(a, b)" kick-starts the right thought. Cheers, -Andrzej
I don't think that
aName =
[ x
, y
, z
]
can be beat for adaptability (i.e. adding/removing/reorganizing
results or _especially_ renaming the declaration). Doesn't do so hot
regarding vertical space though...
On 3/28/07, Greg Buchholz
David House wrote:
I see this a lot. My personal preference is:
mylist = [ foo, bar, baz, qux, quux, foo, bar, baz, qux ]
Or,
mylist = [foo, bar , baz, qux, quux, foo, bar, baz , qux]
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 2007 Mar 29, at 12:26 AM, Nicolas Frisby wrote:
I don't think that
aName = [ x , y , z ]
can be beat for adaptability (i.e. adding/removing/reorganizing results or _especially_ renaming the declaration). Doesn't do so hot regarding vertical space though...
IMHO (just as IYHO above), this cannot be beat: aName = [ x , y , z , ] is perfect. though there are many variations on where 'x ,' is placed relative to the opening square bracket. But... it requires that trailing commas be treated uniformly in the syntax, which they aren't right now. (The above would be legal Python code, so yes, my claim is hypothetical only its application to Haskell.) --Doug
From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Douglas Philips
On 2007 Mar 29, at 12:26 AM, Nicolas Frisby wrote:
I don't think that
aName = [ x , y , z ]
can be beat for adaptability
IMHO (just as IYHO above), this cannot be beat:
aName = [ x , y , z , ]
is perfect. though there are many variations on where 'x ,' is placed relative to the opening square bracket.
While we're on the my-syntax-is-better-n-yours wagon... this works in Haskell *now*, without any changes to language syntax: aName = x : y : z : [] (now, who do I credit for that? I forget...) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
On Wed, Mar 28, 2007 at 10:21:08PM +0200, Benjamin Franksen wrote:
Hi,
I often run into the following issue: I want to write a list of lengthy items like this
mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ]
With the current layout rules this is a parse error (at the closing bracket). Normally I avoid this by indenting everything one level more as in
mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ]
but I think this is a little ugly.
Same issue comes up with parenthesized do-blocks, I would like to write
when (condition met) (do first thing second thing )
So my wish is for a revised layout rule that allows closing brackets (of all sorts: ']', ')', '}') to be on the same indent level as the start of the definition/expression that contains the corresponding opening bracket.
this would be fairly simple by adding a rule to the parser grammer like so list := '[' item* ';'? ']' as in, allow an optional semicolon before any bracketing closing token. as for the other example, I tend to do when (condition met) $ do first thing second thing though, the semicolon thing above would allow the layout you want too. John -- John Meacham - ⑆repetae.net⑆john⑈
On Wed, 28 Mar 2007, Benjamin Franksen wrote:
Hi,
I often run into the following issue: I want to write a list of lengthy items like this
mylist = [ quite_lengthy_list_item_number_one, quite_lengthy_list_item_number_two, quite_lengthy_list_item_number_three ]
participants (14)
-
Andrzej Jaworski -
Bayley, Alistair -
Benjamin Franksen -
David House -
DavidA -
Dougal Stanton -
Douglas Philips -
Greg Buchholz -
Henning Thielemann -
John Meacham -
Nicolas Frisby -
Stefan Monnier -
Steve Schafer -
Tim Chevalier