Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On 18 Dec 2009, at 06:39, Richard O'Keefe wrote: My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. Wouldn't it be something like Editor (Preset (Color Scatter)) in Haskell? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Thu, Dec 17, 2009 at 6:58 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: (Why do people call baStudly syle camel? Is there somewhere in the world a species of camel with three or four humps, like XmlNodeSansChildren?) As near as I can tell (from googling) you're the one calling it baStudlyCaps :) See this mail were you seem to coin the phrase and mention african gender prefix (what is that?): http://www.mail-archive.com/disc...@ppig.org/msg01199.html It seems that if you want this name baStudlyCaps to catch on it should be added to the list of alternate names for camel case: http://en.wikipedia.org/wiki/CamelCase#Variations_and_synonyms Cheers, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Fri, 18 Dec 2009 16:39:21 +1300, you wrote: My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. I wouldn't notice the difference between Preset and Present in either case. And in the latter example, my eyes would actually be drawn away from Preset/Present and towards Colour, noticing that it is spelled incorrectly... Count me in the prefers hyphens camp, by the way. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
One obvious rule is that lower_upperupper can be mapped to lowerupperupper and vice versa, but that upper_upper must be left alone. As for ok_URL, this is a good example of why mixing styles isn't so good. To comply with baStudlyCaps style, it should have been okURL in the first place. (Why do people call baStudly syle camel? Is there somewhere in the world a species of camel with three or four humps, like XmlNodeSansChildren?) On Dec 17, 2009, at 3:55 AM, Daniel Fischer wrote: Am Mittwoch 16 Dezember 2009 15:12:31 schrieb Colin Paul Adams: I tried it. I'm not all that happy with the resulting uncameling. For instance, Database.HaskellDB.Sql.PostgreSQL I'd expect Database.Haskell_DB.Sql.Postgre_SQL Data.Bits.shiftL would that be preferred as shiftL shift_L shift_l OK. lowerupperlower - lower_lowerlower lowerupper - lower_upper otherwise There is of course a conceptually simple way to deal with packages that export identifiers in mixed styles, and that is to create wrappers that re-export the identifiers in a consistent style. As far as I'm concerned, hspp is a tool that lets me write and maintain stuff the way I like it and export it for others to use. (Not that this has happened yet, others are so much better at coming up with great stuff...) If the exported version doesn't work, that means there's a mistake in the original version. It's _nice_ that GHC lets me use -F, but GHC isn't the only compiler in town. By the way, the current design for the readability experiment involves - third year students (because that's what I can get) - three short programs, one written with no compound names (A) and the other two in both underscore (BU, CU) and baStudly (BB, CB) style. - each student reads A, BU, CB or A, BB, CU or A, CU, BB or A, CB, BU in the usual sort of Latin-squarey way and answers some comprehension questions, with times recorded. - age, language spoken at home, previous experience as demographics. Advice and recommendations for the short programs will be gratefully received, but the programs should probably be in an imperative language that isn't one the students are familiar with, maybe Pascal or Ada. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 17, 2009, at 4:45 AM, Ben Millwood wrote: By the way, I like camelCase because I think that in most cases you *don't* want to break identifiers up into their component words My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. Here's another *real* baStudlyCaps identifier taken from a real (and useful) program someone else wrote: WEKA_AttributeSelectionEvaluationRanker_SymmetricalUncert - you read and understand what the function does once, and then you use it as a word in its own right. I defy anyone to recognise WEKA_AttributeSelectionEvaluationRanker_SymmetricalUncert as a word in its own right. Any resemblance to actual English is really just a mnemonic of sorts. Take a look at another typical example of the genre: TransformerFactoryConfigurationError transformer factory configuration error -- the resemblance to actual English is more than accidental. A sample of a little over 2000 Java class names had this length distribution. 1: 10 2: 9 3: 35 4: 55 5: 53 6: 72 7: 97 8: 114 9: 127 10: 158 11: 116 12: 145 13: 150 14: 131 15: 120 16: 109 17: 96 18: 84 19: 56 20: 57 21: 53 22: 53 23: 37 24: 21 25: 29 26: 8 27: 9 28: 5 29: 5 31: 2 33: 3 35: 1 36: 3 37: 2 39: 2 44: 2 47: 1 48: 1 49: 1 50: 1 57: 1 Looking at the number of words in each of these phrases, the distribution is 1: 334 16.5% 2: 893 44.1% 3: 578 28.6% 4: 161 7.5% 5: 43 2.1% 6: 17 0.8% 7: 8 0.4% Now on a sample of English text (the WSJ collection), the commonest word length was 3 letters and the longest was 26. These Java class names are clearly quite unlike the words we're used to reading (which would count against my ideas about readability except that they _are_ quite like English _phrases_). I don't have similar figures handy for Haskell. You thought myExamplesLikeThisAreMadeUp? Nope, things that long and with that many words in the phrase are _not_ rare in seriously baStudly code. If you can see a 57-character 7-word class name as a single word, you have very different eyes from me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Thu, Dec 17, 2009 at 8:39 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On Dec 17, 2009, at 4:45 AM, Ben Millwood wrote: By the way, I like camelCase because I think that in most cases you *don't* want to break identifiers up into their component words My experience has been that in order to make sense of someone else's code you *HAVE* to break identifiers into their component words. With names like (real example) ScatterColorPresetEditor, the eye *can't* take it in at once, and telling the difference between that and ScatterColorPresentEditor would be a pain. Break them up Ada-style as Scatter_Colour_Preset_Editor and Scatter_Colour_Present_Editor and you're away laughing. I don't know what experience you could have had that led you to believe that *I* have to break identifiers into component words. I am kind of just being a pedant, but I think that using the word I throughout this paragraph instead of you will more fairly draw attention to the fact that, throughout it, you are still talking about your own experience. I don't like to get caught up into this kind of argument, but my own opinion is that phrases don't make good words. If we write-text English-language using word-phrase-uninflected as words, no matter-verb the word-spacing, it would be difficulty-hard to read-text. My preferred way to increase the readability of code is to keep names short and *limited in scope*. Luke Here's another *real* baStudlyCaps identifier taken from a real (and useful) program someone else wrote: WEKA_AttributeSelectionEvaluationRanker_SymmetricalUncert - you read and understand what the function does once, and then you use it as a word in its own right. I defy anyone to recognise WEKA_AttributeSelectionEvaluationRanker_SymmetricalUncert as a word in its own right. Any resemblance to actual English is really just a mnemonic of sorts. Take a look at another typical example of the genre: TransformerFactoryConfigurationError transformer factory configuration error -- the resemblance to actual English is more than accidental. A sample of a little over 2000 Java class names had this length distribution. 1: 10 2: 9 3: 35 4: 55 5: 53 6: 72 7: 97 8: 114 9: 127 10: 158 11: 116 12: 145 13: 150 14: 131 15: 120 16: 109 17: 96 18: 84 19: 56 20: 57 21: 53 22: 53 23: 37 24: 21 25: 29 26: 8 27: 9 28: 5 29: 5 31: 2 33: 3 35: 1 36: 3 37: 2 39: 2 44: 2 47: 1 48: 1 49: 1 50: 1 57: 1 Looking at the number of words in each of these phrases, the distribution is 1: 334 16.5% 2: 893 44.1% 3: 578 28.6% 4: 161 7.5% 5: 43 2.1% 6: 17 0.8% 7: 8 0.4% Now on a sample of English text (the WSJ collection), the commonest word length was 3 letters and the longest was 26. These Java class names are clearly quite unlike the words we're used to reading (which would count against my ideas about readability except that they _are_ quite like English _phrases_). I don't have similar figures handy for Haskell. You thought myExamplesLikeThisAreMadeUp? Nope, things that long and with that many words in the phrase are _not_ rare in seriously baStudly code. If you can see a 57-character 7-word class name as a single word, you have very different eyes from me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 18, 2009, at 5:00 PM, Luke Palmer wrote:
On Thu, Dec 17, 2009 at 8:39 PM, Richard O'Keefe o...@cs.otago.ac.nz
wrote:
On Dec 17, 2009, at 4:45 AM, Ben Millwood wrote:
By the way, I like camelCase because I think that in most cases you
*don't* want to break identifiers up into their component words
My experience has been that in order to make sense of someone else's
code you *HAVE* to break identifiers into their component words.
With names like (real example) ScatterColorPresetEditor, the eye
*can't* take it in at once, and telling the difference between that
and ScatterColorPresentEditor would be a pain. Break them up
Ada-style as Scatter_Colour_Preset_Editor and
Scatter_Colour_Present_Editor and you're away laughing.
I don't know what experience you could have had that led you to
believe that *I* have to break identifiers into component words.
Instead of writing you, I could have written one.
The meaning would have been essentially unchanged.
Come ON, I explicitly wrote my experience, what more do you want?
Quite by coincidence, just before opening Mail, I was looking
at some Objective C source code. It's part of quite an interesting,
indeed, award-winning, program. I would like to understand it.
But this is how it's written.
+ (FSManagedObjectContextInspector
*)managedObjectContextInspectorWithmanagedObjectContext:(id)theContext
interpreter:(FSInterpreter *)theInterpreter;
That's all on one line.
Now maybe YOU can see
managedObjectContextInspectorWithmanagedObjectContext
whole and entire as a single word without even trying, not for an
instance, to break it into pieces, but here sit I, and the ONLY
way I can make sense of it is to break it up as
managed object context inspector
with managed object context
This is *real* other people's code. Maybe Haskell is immune
to this sort of thing, but that's how baStudlyCaps plays out
in other languages. I am not making this stuff up. I didn't
even go looking for horrible examples. This is just the kind
of stuff that hits me in the eye.
I don't like to get caught up into this kind of argument, but my own
opinion is that phrases don't make good words.
The question is not whether phrases make good words or not,
although there are very strong recommendations in software engineering
textbooks (going back at least as far as Ledgard and Tauer) that
program identifiers *should* be phrases.
The point is that in the code I find myself trying to read these
days identifiers *ARE* phrases, whether you or I or anyone else
like it or not.
Take another line from that same program (but another file).
[predicateTextView setFont:[NSFont userFixedPitchFontOfSize:
[[NSUserDefaults standardUserDefaults]
floatForKey:@FScriptFontSize]]];
Tell the (predicate text view) to (set [its] font [to])
(NextStep Font's (user (fixed pitch font) (of size))
(Next Step User Defaults' standard user defaults) float[ing point
number] for key FScript font size).
That's presented as one (very wide) line of source code.
It *is* an English sentence with a bunch of words deleted and
some funny punctuation marks added.
This is code that I am not familiar with.
It is obvious that nearly *all* code in the world is code that I am
not familiar with. Talk about how you can read this once you have
become so familiar with it that you can see all these big blobs of
text as single words is talk about what will happen on the Greek
Kalends, as far as I can see. In order to get to that point, FIRST
I must make sense of it from a position of ignorance.
And to do that, I *HAVE* to break the identifiers into words and
read the natural language text that is very nearly there.
How else can I determine the meaning of these identifiers than by
reading them as phrases? They *ARE* phrases! They are MEANT as
phrases. Am I supposed to divine the meanings by Platonic
intuition?
Is there really, honestly, anyone on this list who DOESN'T have to
approach code like
1. - (void)updateAction:(id)sender
2. {
3. [window setTitle:[NSString stringWithFormat:@Inspecting %@ at
address %p,descriptionForFSMessage(inspectedObject), inspectedObject]];
4. [printStringView setFont:[NSFont
userFixedPitchFontOfSize:userFixedPitchFontSize()]];
5. [printStringView setString:printString(inspectedObject)];
6. }
(numbers added to show where the lines start)
by breaking these identifiers into words?
My preferred way to increase the readability of code is to
keep names short and *limited in scope*.
That's good. Haskell code is chock full of one and two letter
highly local identifiers.
I have to (and I do mean have to, there's a group project I'm
supposed to contribute to) read stuff like
1. double ANT_mean_average_precision::average_precision(long topic,
ANT_search_engine *search_engine)
2. {
3. ANT_relevant_topic *got;
4. ANT_relevant_document key, *relevance_data;
5. long long current, found_and_relevant;
6. double precision;
7.
8.
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Thu, Dec 17, 2009 at 10:39 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On Dec 18, 2009, at 5:00 PM, Luke Palmer wrote: My preferred way to increase the readability of code is to keep names short and *limited in scope*. That's good. Haskell code is chock full of one and two letter highly local identifiers. I am actually rather ambivalent to this practice. I was referring more to the 4-8 letter, 1-2 word range: functions named collect or diagonals or split. A name like this together with a type signature is frequently enough to uniquely identify the function in question; without a good name, not so much. I find one and two letter identifiers the best way in a few situations, eg. in map (x:xs) = ..., where there is hardly a better name for them (head and tail perhaps... but it is blindly clear from context what they are...). On the other hand, a function like Martin Escardo's: find_vii :: (Cantor - Bool) - Cantor find_vii p = b where b = id'(\n - if q n (find_vii(q n)) then Zero else One) q n a = p(\i - if i n then b i else if i == n then Zero else a(i-n-1)) is pretty rough reading for me. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Mittwoch 16 Dezember 2009 07:56:26 schrieb Colin Paul Adams:
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes:
Daniel Now, would you be interested in a transformation the other
Daniel way round, so that you can read other people's code in
Daniel your preferred style?
I would, applied to the output of haddock, at least.
As a pre-alpha version:
module Main (main) where
import Data.Char (isUpper, isLower, toLower)
main :: IO ()
main = interact unCamel
unCamel :: String - String
unCamel ('':cs) = '' : inTag cs
unCamel (a:bs@(b:cs))
| isLower a isUpper b= a : '_' : toLower b : unCamel cs
| otherwise = a : unCamel bs
unCamel cs = cs
inTag :: String - String
inTag ('':cs) = '' : unCamel cs
inTag (a:cs)= a : inTag cs
inTag []= []
Compile, run with
./unCamel /path/to/HaddockOutput.html /path/to/Haddock_output.html
(or whatever Windows uses to redirect stdin and stdout)
This makes a few not-well-founded assumptions about haddock's output. Try it on
a couple
of files, report bugs. If it works satisfactorily, we can add a front-end to
make
transformation easy (like, pass an input directory and an output directory on
the command
line, and it recursively copies the directory content, transforming all .html
files,
giving you a complete documentation with working links).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
Daniel Fischer daniel.is.fisc...@web.de writes: Am Dienstag 15 Dezember 2009 03:04:43 schrieb Richard O'Keefe: On Dec 14, 2009, at 5:11 PM, Daniel Fischer wrote: 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. But the insanely abbreviated example did not provide such a reason. Of course not. But if you expand it - and it's not difficult, even when insanely abbreviated -, the resulting sentence gives a possible reason: Maybe it's because the underscore style is considered far uglier and less readable by others. If the early Haskellers felt that way, isn't it perfectly natural that they chose the camelCase style? As one of the early Haskellers, I definitely preferred underscores, because my intuition told me that it was closer in appearance to normal English¹ text, and my belief was that even programmers read more English than code. Unfortunately I'm not a very persuasive person, and couldn't argue my case (beyond having underscores /permitted/). The problem is that once people have spent some time using one style or other, their ability to self-analyse their reading of it becomes negligible. Ugly and less readable become synonymous with not the style I'm used to, irrespective of actual effects on reading speed. And introspection is a notoriously bad method of anyalysing psychological factors in the first place. This really should have been decided with proper experiments. Of course, they may have had entirely different reasons, or no concrete reason at all and it just happened. In the absence of hard data, it only takes a slight bias in exposure among members of the committee to tip a decision the wrong way. [1] and quite a high proportion of other natural languages. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Jon Fairbairn jon.fairba...@cl.cam.ac.uk writes: As one of the early Haskellers, I definitely preferred underscores, because my intuition told me that it was closer in appearance to normal English¹ text, [1] and quite a high proportion of other natural languages. Which makes me wonder - might there be a (natural) language bias as well? I'm sure most English-speaking people would have noticed that German tends to contain huge words from contracting adjectives and nouns that in English would be separate. (Cf. Daniel's example Anlagenmechanikermeister - it almost makes me wish for Germans to adopt camel-casing and making it AnlagenMechanikerMeister. In English, I guess it would be 'factory lead mechanic' or some such.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Ketil == Ketil Malde ke...@malde.org writes: [1] and quite a high proportion of other natural languages. Ketil Which makes me wonder - might there be a (natural) language Ketil bias as well? Sure. Different languages have different orthographical traditions. IMHO a project should adopt the styles of the natural language it uses for comments (assuming that the project leader has mandated a language for comments). The Haskell standard libraries don't do this. There is also the question of whether a programming language should be adaptable to the natural language used in a project (e.g. spelling of keywords). I have tried to advocate that it should, several times in the past. But no-one has ever agreed with me on this. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes:
Daniel As a pre-alpha version:
Daniel
Daniel module Main (main) where
Daniel import Data.Char (isUpper, isLower, toLower)
Daniel main :: IO () main = interact unCamel
Daniel unCamel :: String - String unCamel ('':cs) = '' : inTag
Daniel cs unCamel (a:bs@(b:cs)) | isLower a isUpper b = a :
Daniel '_' : toLower b : unCamel cs | otherwise = a : unCamel bs
Daniel unCamel cs = cs
Daniel inTag :: String - String inTag ('':cs) = '' : unCamel
Daniel cs inTag (a:cs) = a : inTag cs inTag [] =
Daniel []
Daniel Compile, run with
Daniel ./unCamel /path/to/HaddockOutput.html
Daniel /path/to/Haddock_output.html
Daniel (or whatever Windows uses to redirect stdin and stdout)
Daniel This makes a few not-well-founded assumptions about
Daniel haddock's output. Try it on a couple of files, report
Daniel bugs.
I tried it.
I'm not all that happy with the resulting uncameling.
For instance,
Database.HaskellDB.Sql.PostgreSQL
goes to
Database.Haskell_dB.Sql.Postgre_sQL
which is uglier than before.
I.m not sure how I would write this going the other way, using
Richard's hspp pre-processor.
I'd want to write Database.Haskell_DB.Sql.Postgresql, but I'd guess
I'd have to write it as Database.Haskell_DB.Sql.Postgre_s_q_l or just
Database.Haskell_DB.Sql.PostgreSQL :-(
Anyway, I'm having trouble with using Richard hspp. It changes ok_url
to okUrl, but in fact the function concerned is named ok_url in
Network.URL, so the pre-processor would have to be applied as part of
cabal install for all packages.
I don't think it's practical to edit all the .cabal packages as they
come in to say:
ghc-options: -F -pgmF hspp
and cabal install does not recognize this line if I add to to my
~/.cabal/config file.
Duncan, is there a way this can be done?
--
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Wed, 2009-12-16 at 14:12 +, Colin Paul Adams wrote: I don't think it's practical to edit all the .cabal packages as they come in to say: ghc-options: -F -pgmF hspp and cabal install does not recognize this line if I add to to my ~/.cabal/config file. Duncan, is there a way this can be done? I hope not! :-) If you want to view API docs in this alternate style then the right place to insert your hack is in haddock. You can then build all your packages with --haddock-options=--transform_to_underscore_style. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/16 Duncan Coutts duncan.cou...@googlemail.com: On Wed, 2009-12-16 at 14:12 +, Colin Paul Adams wrote: I don't think it's practical to edit all the .cabal packages as they come in to say: ghc-options: -F -pgmF hspp and cabal install does not recognize this line if I add to to my ~/.cabal/config file. Duncan, is there a way this can be done? I hope not! :-) If you want to view API docs in this alternate style then the right place to insert your hack is in haddock. You can then build all your packages with --haddock-options=--transform_to_underscore_style. Yes, I understand that. I was actually talking about the reverse transformation. Richad O'Keefe has written a pre-processor (hspp) that will translate underscore (or hyphen) style to camelCase. By putting the above line in my project's .cabal file, it worked only up to a point. the point where it broke is because I was using ok_url from Network.URL. my use of it was getting translated to okURL, which causes a compile failure. So I could fix this failure by unpacking Network.URL, editing it's .cabal file to add the above line, and re-installing it.. But this is likely to trickle through all the packages I have installed. So I was looking for a way to make it the default. But I guess this won't scale (if a package already has a pgmF preprocessot, there would be a conflict). -- Colin Adams Preston, Lancashire, ENGLAND ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Mittwoch 16 Dezember 2009 15:12:31 schrieb Colin Paul Adams:
I tried it.
I'm not all that happy with the resulting uncameling.
For instance,
Database.HaskellDB.Sql.PostgreSQL
goes to
Database.Haskell_dB.Sql.Postgre_sQL
which is uglier than before.
Oy. Didn't think of that. If you can live with
Database.Haskell_DB.Sql.Postgre_SQL
the fix is easy:
unCamel :: String - String
unCamel ('':cs) = '' : inTag cs
unCamel (a:b:c:cs)
| isLower a isUpper b isUpper c = a : '_' : b : c : unCamel cs
unCamel (a:bs@(b:cs))
| isLower a isUpper b= a : '_' : toLower b : unCamel cs
| otherwise = a : unCamel bs
unCamel cs = cs
Another point is, what about things like
Data.Bits.shiftL
would that be preferred as
shiftL
shift_L
shift_l
?
Generally, when shall we flatten the hump,
1) always -- not
2) unless followed by an uppercase letter
3) when followed by a lowercase letter
I think, 3) is better than 2), things like for_m_ or map_m_ don't look right to
me.
All of them are easy to implement, the question is what to implement.
What about
feedO'Houlihan?
IMO, it should clearly go to feed_O'Houlihan
So, perhaps
unCamel :: String - String
unCamel ('':cs) = '' : inTag cs
unCamel (a:b:c:cs)
| isLower a isUpper b isLower c = a : '_' : toLower b : c : unCamel cs
unCamel (a:bs@(b:cs))
| isLower a isUpper b= a : '_' : b : unCamel cs
| otherwise = a : unCamel bs
unCamel cs = cs
(gives Database.Haskell_DB.Sql.Postgre_SQL, shift_L, for_M_ [that's not
optimal, any ideas
what to make of that?], feed_O'Houlihan).
Please test, report shortcomings.
I.m not sure how I would write this going the other way, using
Richard's hspp pre-processor.
I'd want to write Database.Haskell_DB.Sql.Postgresql, but I'd guess
That would become really complicated. I'm afraid if you want that, you'll have
to do it
yourself.
I'd have to write it as Database.Haskell_DB.Sql.Postgre_s_q_l or just
Database.Haskell_DB.Sql.PostgreSQL :-(
Anyway, I'm having trouble with using Richard hspp. It changes ok_url
to okUrl, but in fact the function concerned is named ok_url in
Network.URL, so the pre-processor would have to be applied as part of
cabal install for all packages.
Oh, great. There we have a preprocessor's nightmare, a package using both
styles.
Let us think what to do with such things.
I don't think it's practical to edit all the .cabal packages as they
come in to say:
ghc-options: -F -pgmF hspp
and cabal install does not recognize this line if I add to to my
~/.cabal/config file.
Duncan, is there a way this can be done?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes: Daniel Database.Haskell_DB.Sql.Postgre_SQL Actually, I would be semi-happy with Database.Haskell-DB.Sql.Postgre-SQL (obviously we need an option whether to use hypens or underscores. I prefer hyphens.) Daniel Data.Bits.shiftL Daniel would that be preferred as Daniel shiftL Daniel shift_L Daniel shift_l I think I prefer shift-left :-) I'd settle for the last. Daniel Generally, when shall we flatten the hump, 1) always -- Daniel not 2) unless followed by an uppercase letter 3) when Daniel followed by a lowercase letter I'm nit sure. i think a more sophisticated rule might be needed. Daniel feedO'Houlihan? Daniel IMO, it should clearly go to feed_O'Houlihan Yes, I think so. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Wed, Dec 16, 2009 at 2:55 PM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
unCamel :: String - String
unCamel ('':cs) = '' : inTag cs
unCamel (a:b:c:cs)
| isLower a isUpper b isLower c = a : '_' : toLower b : c : unCamel
cs
unCamel (a:bs@(b:cs))
| isLower a isUpper b = a : '_' : b : unCamel cs
| otherwise = a : unCamel bs
unCamel cs = cs
Excuse my pedantry, but: writeToList - write_toList.
I think the third equation needs to be:
unCamel (a:b:cs@(c:_))
| isLower a isUpper b isLower c = a : '_' : toLower b : unCamel cs
so that the third character is not ignored in subsequent parses.
By the way, I like camelCase because I think that in most cases you
*don't* want to break identifiers up into their component words - you
read and understand what the function does once, and then you use it
as a word in its own right. Any resemblance to actual English is
really just a mnemonic of sorts.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Mittwoch 16 Dezember 2009 16:08:43 schrieb Colin Paul Adams: Daniel Database.Haskell_DB.Sql.Postgre_SQL Actually, I would be semi-happy with Database.Haskell-DB.Sql.Postgre-SQL (obviously we need an option whether to use hypens or underscores. I prefer hyphens.) That's no problem. Hyphens would also circumvent the Network.URL problem :) Of course, you'd have to set up a not-too-complicated way to type \x2010 in your editor. I think I prefer shift-left :-) Sure, mate, that's absolutely not going to be a bitch :-/ Use (..) = shiftL (..) = shiftR instead? I'd settle for the last. Also map_m and fiter_m c? And map_m_, for_m_ ? Resp. shift-l, map-m, map-m_ ? Would that be 4) flatten, when followed by lowercase letter, nothing or underscore? Daniel Generally, when shall we flatten the hump, 1) always -- Daniel not 2) unless followed by an uppercase letter 3) when Daniel followed by a lowercase letter I'm nit sure. i think a more sophisticated rule might be needed. Okay, let's start to find it. We won't find something which is perfect in all cases, but perhaps something that's good enough in almost all cases and never too ugly. Should aBC... - a_BC... / a-BC... in all cases? If not, in which cases what other behaviour? Should aBc... - a_bc... / a-bc... always? If not, what else? aB - a_b /a-b ? aB' - a_b' /a-b' ? aB_ - ? aB'c... - ? aB'C... - ? Daniel feedO'Houlihan? Daniel IMO, it should clearly go to feed_O'Houlihan Yes, I think so. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Mittwoch 16 Dezember 2009 16:45:01 schrieb Ben Millwood:
On Wed, Dec 16, 2009 at 2:55 PM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
unCamel :: String - String
unCamel ('':cs) = '' : inTag cs
unCamel (a:b:c:cs)
| isLower a isUpper b isLower c = a : '_' : toLower b : c :
unCamel cs unCamel (a:bs@(b:cs))
| isLower a isUpper b = a : '_' : b : unCamel cs
| otherwise = a : unCamel bs
unCamel cs = cs
Excuse my pedantry, but: writeToList - write_toList.
Nothing to excuse, thanks for spotting it so quickly.
I think the third equation needs to be:
unCamel (a:b:cs@(c:_))
| isLower a isUpper b isLower c = a : '_' : toLower b : unCamel cs
so that the third character is not ignored in subsequent parses.
Yep. That comes from posting code that never saw your editor :(
By the way, I like camelCase because I think that in most cases you
*don't* want to break identifiers up into their component words - you
read and understand what the function does once, and then you use it
as a word in its own right. Any resemblance to actual English is
really just a mnemonic of sorts.
I'm with you.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Dienstag 15 Dezember 2009 03:04:43 schrieb Richard O'Keefe: On Dec 14, 2009, at 5:11 PM, Daniel Fischer wrote: 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. But the insanely abbreviated example did not provide such a reason. Of course not. But if you expand it - and it's not difficult, even when insanely abbreviated -, the resulting sentence gives a possible reason: Maybe it's because the underscore style is considered far uglier and less readable by others. If the early Haskellers felt that way, isn't it perfectly natural that they chose the camelCase style? Of course, they may have had entirely different reasons, or no concrete reason at all and it just happened. You still haven't explained what the reason is supposed to be: it can't be that baStudlyCase salvages the readability of abbreviation because it doesn't. No, nothing salvages insane abbreviation. Indeed, it makes it worse, because you can't always tell where one abbreviation ends and another begins. In teaching an information retrieval paper, one of my favourite examples is unionised. Does it mean (union+ise)+ed having had the workers organised into a union orun+(ion+ised) not having had its molecules turned into ions. When I mean the latter, I always write un-ionised. Yes, some words are ambiguous. Although I too find un-ionised superior, unIonised also works - okay in a serif font, just barely in sans-serif. Now consider an actual Java class name, where I genuinely didn't know what the answer was. INSURL baStudlyCaps style for Java doesn't allow underscores in class names. (This is actual Sun code.) Is this something to do with insurance? Is this something to do with URLs for the US Immigration and Nationalization Service? Are Inertial Navigation Systems involved? Is the mention of 'URL' anything to do with URLs, or should this be parsed something like (I) (NSU) (RL)? With underscores, the actual parsing, INS_URL, would be unambiguous. Or take NVList, another real name. Is it an NV_List (where I don't know what NV is), an N_V_List (where I don't know what N and V are), or an N_VList (where I do know what a vlist is). In fact it's a Name_Value_List. I _might_ have had a clue with N_V_List... Do you agree that both are horrible names regardless of whether one uses camel case or underscores? INSURL even worse than NVList? Although, considering that it's in package com.sun.corba.se.impl.naming.namingutil (not that I find that package name particularly well chosen), the URL part is pretty evident. Nevertheless, ugh, and indeed, INS_URL would be better. Still better would be a name at least partially resolving INS (it's not the International Necronautical Society, I hope, that would be beastly to expand). Considering the other, NamedValueList or Named_Value_List would be far better than any sprinkling of underscores over NVList. My point here is that if you separate words with spaces, dots, hyphens, underscores, backslashes, or almost anything, you are going to have _much_ less trouble with abbreviations than if you just jam them together baStudlyCaps-style. Agreed, that kind of shitty names are less bad with underscores. As for my parody of baStudlyCaps, thatIsExactlyHowItLooksToMe. It's not how it looks to me. I think you could find that written in many texts on aesthetic relativism. They are empirically wrong. Interesting. I thought the question whether there is an objective quality of beauty was metaphysical and thus it's impossible to be empirically right or wrong in that respect. So, pray tell, what is the physical substrate of beauty, how can one measure it? Both are judgments based on their respective preferences and nothing else I disagree. Sometimes, people can articulate _why_ they like or dislike things. For example, I like anything spacious and bright. This explains very well why I prefer landscapes (spacious) to portraits (not spacious). Yes, it does. But it doesn't mean that landscapes are objectively beautiful and portraits are objectively ugly. There are people who prefer portraits to landscapes. They are not wrong, they just have different preferences. When it comes to depictions of plants, animals, people, and so on, I prefer healthy to unhealthy, friendly appearance to hostile/dangerous. Yup. Although my favourite is Toulouse-Lautrec and I like Brueghel (P. the elder) and Bosch too, in general I prefer nice and friendly. Given that, you could probably predict my response to most paintings fairly well. If I and anyone I personally knew disagreed about which of two paintings was better, Are we here at the core of a misunderstanding? I'm not talking about better, only about beautiful. I would expect to find that we quickly reached agreement about what features
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Daniel == Daniel Fischer daniel.is.fisc...@web.de writes: Daniel Now, would you be interested in a transformation the other Daniel way round, so that you can read other people's code in Daniel your preferred style? I would, applied to the output of haddock, at least. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Just to toss my own cents into the camelCase versus under_score discussion: I personally prefer to use camelCase for functions and types and under_score for variables and value so that the two can be easily visually distinguished. For example, callFunctionWith first_variable second_variable This is arguably either the best or the worst of both worlds. :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 14, 2009, at 5:11 PM, Daniel Fischer wrote: 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. But the insanely abbreviated example did not provide such a reason. You still haven't explained what the reason is supposed to be: it can't be that baStudlyCase salvages the readability of abbreviation because it doesn't. Indeed, it makes it worse, because you can't always tell where one abbreviation ends and another begins. In teaching an information retrieval paper, one of my favourite examples is unionised. Does it mean (union+ise)+ed having had the workers organised into a union or un+(ion+ised) not having had its molecules turned into ions. When I mean the latter, I always write un-ionised. Now consider an actual Java class name, where I genuinely didn't know what the answer was. INSURL baStudlyCaps style for Java doesn't allow underscores in class names. (This is actual Sun code.) Is this something to do with insurance? Is this something to do with URLs for the US Immigration and Nationalization Service? Are Inertial Navigation Systems involved? Is the mention of 'URL' anything to do with URLs, or should this be parsed something like (I) (NSU) (RL)? With underscores, the actual parsing, INS_URL, would be unambiguous. Or take NVList, another real name. Is it an NV_List (where I don't know what NV is), an N_V_List (where I don't know what N and V are), or an N_VList (where I do know what a vlist is). In fact it's a Name_Value_List. I _might_ have had a clue with N_V_List... My point here is that if you separate words with spaces, dots, hyphens, underscores, backslashes, or almost anything, you are going to have _much_ less trouble with abbreviations than if you just jam them together baStudlyCaps-style. As for my parody of baStudlyCaps, thatIsExactlyHowItLooksToMe. I think you could find that written in many texts on aesthetic relativism. They are empirically wrong. Both are judgments based on their respective preferences and nothing else I disagree. Sometimes, people can articulate _why_ they like or dislike things. For example, I like anything spacious and bright. This explains very well why I prefer landscapes (spacious) to portraits (not spacious). When it comes to depictions of plants, animals, people, and so on, I prefer healthy to unhealthy, friendly appearance to hostile/dangerous. Given that, you could probably predict my response to most paintings fairly well. If I and anyone I personally knew disagreed about which of two paintings was better, I would expect to find that we quickly reached agreement about what features were _present_ to what _degree_ and about the technical standard of the work (on a rather coarse scale, but enough). The differences could be explained by the relative _weights_ we gave to the various features. Just as I have learned how to prepare tea and cook onions so that my wife will enjoy them, although I dislike the one and detest the other, so I would expect to be able to learn how to predict someone's aesthetic taste fairly well. Maybe we do agree. It wasn't clear whether by preferences you meant weights or outcomes. The thing is, if preferences means outcomes, there's no reason to expect that people will ever agree, whereas if it means weights, then it should be possible to find or construct examples differing in a single feature where two people with different weights will agree on which is better. In the same way, when it comes to coding style, it may well be that we are responding to the same objective properties of styles, but weighting them differently. It appears, for example, that we both perceive abbreviation, and we both give it a negative weight. It is therefore to be expected that given two versions of a program in which the *only* thing changed is the degree and/or nature of abbreviation, we'll agree which is better and which is worse. For me to accept personal preference as a final explanation of something would be to accept an end to rational investigation. If it were just a matter of experience, then this experience should surely have taught me to love baStudlyCaps. No. It should have tought you to *read* camelCase - unless your aversion is so strong that you actively refuse to learn reading it. Where did you ever get the idea that I can't *read* baStudlyCaps? Just because I can read it doesn't mean that I can't read something else *better*. Life is hard enough without accepting unnecessary difficulties, even if they are moderately small ones. Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), I gave the wrong response to that yesterday. Later in the common room I realised what the perfect answer is: newspapers are ordinary text, newspaper columns are
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
I too thought of using NBSP as a word separator. Unicode is replete with spaces of various widths and usages. I suggest, however, that Haskell code does tend to require careful reading, and that ambiguities (like the word boundaries that baStudlyCapsMakesSoHardToLocateQuickly) that we might tolerate in contexts where the text is fairly predictable are far less tolerable in stuff that requires a close reading. One of the problems with baStudlyCaps is that it can give Stress to the wrong words. Take takeWhile as an example. The while bit is humanly recoverable because a function follows it. The thing that you most need to see is take. But it's the least informative part of the name (While) that is stressed. The visible blank U+2423 (Unicode calls it an Open Box, but its function is to visibly indicate a blank) might␣just␣do, but you might as well use underscores (or hyphens). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 11, 2009, at 11:37 PM, Johannes Laire wrote: On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf Compare: someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar. To me the gaps in the second one were clear and distinct. In any case, it's not clear that you *need* to see that there are 4 identifiers. You need to see the *first* identifier, and then you need to see the second, c, but let's face it, how often do you need to count the words in a sentence at a glance? And what good does it do to know there are four identifiers if you have to go back with a magnifying class to tell what the identifiers mean? I wrote a little program to search for runs of identifiers without intervening newlines or other tokens. I fed it 56,322 lines of Haskell from various sources. Here's the distribution: Len Tally iCap iCap is the average number of internal 1 84,474 0.21 capital letters in all of the words in 2 27,092 0.32 a run. 3 9,273 0.44 4 3,176 0.45 5866 0.49 6165 0.47 7 87 0.36 8 98 0.73 9 42 0.36 10 9 0.22 11 5 0.20 12 7 0.71 13 1 0.00 The longest run was j then Q i xs ys j else Q j ys xs i which would be the same under any word separation variant. We see from the iCap column that on the whole, the average number of internalCapitals per run is less than one. Looking in some detail at the runs with 4 words, I found that the typical pattern is someHairyGreatFunctionName i x xs with a touch of if okToProceedWith x then In fact, out of 3,176 runs with four words, 2,144 of them didn't have any internal capitals in the first place, so would not be at all affected by a change in word separation style. Having examined the remaining 1032 cases with some care, I honestly couldn't find any cases whose readability was worsened by by underscore separation. Don't forget, some of the arguments are constructors, and using underscore (or hyphen) separation makes it *easier* to see them, because they no longer look like parts of identifiers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. Not a bit of it. mb_t's_bcs the ndrscr_stl was NOT playing fair and you knew it. I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. I guess we must mean different things by readable then. I've approached my head of department about running an experiment. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, Yes, it is really unclear. It read as x (granted that y). For clarity, it should have been (still extremely ugly, granted that underscore-style with nonabbreviated words is not unreadable). Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. Where is it written that aesthetic judgements are _entirely_ a matter of personal preference? As a student I was in the Archaeological society. One of the things I learned was this: - many ancient cultures would ritually kill grave goods - some grave goods would be smashed up, others would just have a chip out of them - as a rule, the ones that were least damaged were the ones the archaeologists considered to be the most beautiful (after repair). If an aesthetic sense about pots can be shared by modern archaeologists and people living five thousand years ago, it's hardly entirely personal. What you may not appreciate is that I have been a Smalltalk programmer for a long time. I've read and written a lot of code like printSolutions (self sendSolutionsUsing: Empty and: Empty to: [:p :n | Transcript nextPutAll: 'p = '; print: p; nextPutAll: ', n = '; print: n; nextPut: $.; cr. true stop after reporting first solution] ) ifFalse: [ Transcript nextPutAll: 'No solutions.'; cr]. If it were just a matter of experience, then this experience should surely have taught me to love baStudlyCaps. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. I doubt that. Until the evidence is in, what other reasonable working assumption is there? Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), OK, let's try it. Shakespeare sonnet number 1, first four lines, but split into shorter chunks With spaces: From fairest creatures we desire increase, That thereby beauty's rose might never die, But as the riper should by time decease, His tender heir might bear his memory: With underscores: From fairest_creatures we desire_increase, That thereby beauty's_rose might_never_die, But as the_riper should by_time decease, His tender_heir might_bear his_memory: With baStudlyCaps: From fairestCreatures we desireIncrease, That thereby beauty'sRose mightNeverDie, But as theRiper should byTime decease, His tenderHeir mightBear hisMemory: baStudlyCaps doesn't read any better with short lines. that I'd be very wary to transfer the findings for one to the other. It's not uncommon for style guides to explicitly recommend that program code should be spaced like text. Apple notoriously violate this in Objective C. Where Smalltalk would have this sendSolutionsUsing: Empty and: Empty to: that Objective C practice is to write [this sendSolutionsUsing:Empty and:Empty to:that] If somebody claimed that of x - take_while some_condition some_list and x - takeWhile someCondition someList either was objectively more readable than the other, I wouldn't believe it without lots and lots of hard evidence. Persaude a man against his will, he's of the same opinion still. How _much_ evidence? That's an artificial example. Haskell code doesn't tend to look like that. It's much more
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Montag 14 Dezember 2009 01:44:16 schrieb Richard O'Keefe: On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. Not a bit of it. mb_t's_bcs the ndrscr_stl was NOT playing fair and you knew it. 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. For that, I deliberately used an unrealistically exaggerated example of unreadable underscores. Even more unrealistic than your camelCase parody. The very next thing, I said that full_word_underscores is *not* unreadable, making clear (apparently not to you, sorry about that) that the example is not to be taken at face value. 2. Below, you say that it was an honest misunderstanding, so it's okay then. I didn't expect that to be the case but suspected intentional misinterpretation. I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. I guess we must mean different things by readable then. By readable, I mean (broadly) easy to read. Of course, some find is_considered far_uglier by_others easier to read, others harder, and yet others find both equally easy to read. I have no difficulty believing that some find either of the styles hard to read, but I don't expect experienced programmers to be in that group. I've approached my head of department about running an experiment. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, Yes, it is really unclear. It read as x (granted that y). Aha. English more fragile than thought. Sorry. For clarity, it should have been (still extremely ugly, granted that underscore-style with nonabbreviated words is not unreadable). No, that is not what I meant. [Granted,] Underscore-style with nonabbreviated words is not unreadable. Even with written-out words, underscore-style is still extremely[1] ugly. [1] This, however, is an exaggeration as far as I'm concerned. I find the underscore-style ugly, but not extremly so. It was your amazinglyUgly which caused it to appear in that sentence. Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. Where is it written that aesthetic judgements are _entirely_ a matter of personal preference? I think you could find that written in many texts on aesthetic relativism. Doesn't matter, though. Of course, one's personal preferences aren't developed in a vacuum, they are strongly influenced by genes and society. So a lot of preferences are shared within a culture and even across cultures and aesthetic judgments aren't entirely *individual*. Nevertheless, I'm convinced that there is no Platonic idea Beauty (or Ugliness) and that if A says that van Gogh's Sunflowers is a beautiful picture while B says it's ugly, it's not the case that one is objectively right, the other wrong. Both are judgments based on their respective preferences and nothing else (unless: lying, acting, succumbing to social pressure, other reasons to not express one's actual opinion). As a student I was in the Archaeological society. One of the things I learned was this: - many ancient cultures would ritually kill grave goods - some grave goods would be smashed up, others would just have a chip out of them - as a rule, the ones that were least damaged were the ones the archaeologists considered to be the most beautiful (after repair). If an aesthetic sense about pots can be shared by modern archaeologists and people living five thousand years ago, it's hardly entirely personal. Depends on what you mean by entirely personal. All I'm saying is that one can find a thing beautiful which another finds ugly. What you may not appreciate is that I have been a Smalltalk programmer for a long time. I've read and written a lot of code like printSolutions (self sendSolutionsUsing: Empty and: Empty to: [:p :n | Transcript nextPutAll: 'p = '; print: p; nextPutAll: ', n = '; print: n; nextPut: $.; cr. true stop after reporting first solution] ) ifFalse: [
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. The problem with that text is *NOT* the underscores but the insanely heavy abbreviation. As stated in the parenthesis immediately afterwards. We all agree that insanely heavy abbreviation is bad, but do you *really* want to claim that mbT'sBcs the ndrscrStl isConsidered farUglier and lessReadable byOthers is readable? I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, or did you intentionally choose the bracketing you did to make a polemical point? (This is a serious enquiry about the English language. In German, the analogous construction to granted, a, but b [zugegeben, a, aber b] is parsed (granted, a), but b, can it really be parsed as granted, (a, but b) in English?) (granted, ... is not unreadable. But it is still ...) Clearly, *I* grant - or admit, concede - that it is *readable*. Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. I don't believe that it _is_ a matter of personal preference. I believe that even readability is strongly influenced by personal preference (more by experience - what you're used to). However, the sentence about preference was more concerned with aesthetics. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. I doubt that. Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), that I'd be very wary to transfer the findings for one to the other. If somebody claimed that of x - take_while some_condition some_list and x - takeWhile someCondition someList either was objectively more readable than the other, I wouldn't believe it without lots and lots of hard evidence. I believe you find the first more readable, however, for me the underscores push the space-separated parts together, so that I have the tendency to bracket it x - take (while some) (condition some) list on first glance. It resolves when focusing on the line, however. (And, of course, the problem doesn't turn up for x - take_while (= 1000) [3,7 .. ] or similar.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
x - take_while some_condition some_list and x - takeWhile someCondition someList x - take-while some-condition some-list As someone who is dyslexic, I find both camelCase and dashes far easier to read than underscores. I find it hard to count the words in the underscore version - the underscores and spaces confuse me. Dashes do not, presumably because they are 'within' the line of sight for the letters. However, I can't help feeling that if we use good IDEs, we could 'internationalize' identifiers into english/french/chinese/camel/dash or whatever. Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Here is a (slightly mischievous) proposal. Allow the Unicode non-breaking space character (nbsp; in HTML) as a valid character in a varid or conid. :-) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Malcolm == Malcolm Wallace malcolm.wall...@cs.york.ac.uk writes: there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Malcolm Here is a (slightly mischievous) proposal. Malcolm Allow the Unicode non-breaking space character (nbsp; in Malcolm HTML) as a valid character in a varid or conid. Malcolm :-) I thought of that one too (seriously). It has the disadvantage that the syntax is ambiguous to the human eye without tool support (e.g. highlighting). On the other hand humans are good at coping with such ambiguity (we do it all the time in spoken language - and delight in puns. And in written language, set is indistinguishable from set, which is indistinguishable from set, which ... - to however many distinct meanings for the word set are currently recognized). -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf Compare: someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar. So, while underscores more clearly separate words in a single *identifier* and make it easier to read, in some cases I think they make *code* with many identifiers harder to read for exactly the same reason. In languages where function application looks like f(x,y,z) instead of f x y z this isn't a problem and I often use underscores. -- Johannes Laire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/11 Johannes Laire johannes.la...@gmail.com: On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf Compare: someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux Before even reading your paragraph below, I thought the second one was easier to read :) In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar. So, while underscores more clearly separate words in a single *identifier* and make it easier to read, in some cases I think they make *code* with many identifiers harder to read for exactly the same reason. In languages where function application looks like f(x,y,z) instead of f x y z this isn't a problem and I often use underscores. Your example should be seen with a monospaced font to be fair thought, as programming is usually done with such a font. (But both lines are easier with a monospaced font.) Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Richard O'Keefe o...@cs.otago.ac.nz writes: You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. Haskell already has this problem with ., where we generally need (As somebody pointed out, this is usually unambigous) to put spaces around . with the meaning composition and not put spaces around other uses. With implicit parameters, this also goes for (?). Is anybody using that extension still? It's a problem that COBOL solved a long time ago: COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. That we all program in COBOL these days shows how important this issue is :-) Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that I prefer underscored_words myself, but just like periods for hierarchical modules, this is water under the bridge. In sum, perhaps the net effect of this convention is positive: it encourages short variable names. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
To Underscore or Not to Underscore Richard O'Keefe and I were privately discussing the relative merits of his and my approach. We have come to an agreement. It concerns whether or not hyphens should be replaced with underscores. The following is my response to his most recent letter: I do not believe your approach given what you wrote here will create the sort of ambiguity I feared could be introduced. If an ambiguity results, it could be fixed. As I would put it, you hope to harmonize the word breaking styles by a process similar to though slightly more involved than what is done to remove case sensitivity in some languages. As layout is concerned only leading white space needs to be preserved. Anything else could be regarded as a superstition (not to say that computer scientists are superstitious). What you hope to do is kill two birds with one stone. If the only goal is to run everything through a preprocessor my approach seems to make the greatest sense, but if you also hope to harmonize the representation of word breaking styles, then what you are advocating seems to make greater sense. Your approach seems more consistent with Haskell traditions than mine. Therefore, I concede. You have successfully argued your point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? 'Tis a matter of personal preference. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Not to mention that in Emacs with glasses-mode enabled camelCase can be made even more readable (my personal favorite is highlighting internal capital letters with bold). Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? 'Tis a matter of personal preference. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! The problem with that text is *NOT* the underscores but the insanely heavy abbreviation. We all agree that insanely heavy abbreviation is bad, but do you *really* want to claim that mbT'sBcs the ndrscrStl isConsidered farUglier and lessReadable byOthers is readable? (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! I don't believe that it _is_ a matter of personal preference. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. If I can get approval to run an experiment, and it turns up evidence that baStudlyCapsIsMoreReadable, then I'll change my preference. read ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 11, 2009, at 3:05 AM, Miguel Mitrofanov wrote: Not to mention that in Emacs with glasses-mode enabled camelCase can be made even more readable (my personal favorite is highlighting internal capital letters with bold). And there is some reason why letters following underscores could not be similarly highlighted? Having to use machine assistance to read baStudlyCaps is pretty damning. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
Deniz Dogan deniz.a.m.do...@gmail.com writes: 2009/12/8 Jon Fairbairn jon.fairba...@cl.cam.ac.uk: Deniz Dogan deniz.a.m.do...@gmail.com writes: [...] allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax I just like the standard Lisp naming convention better than camel casing and saw someone on #haskell mentioning it the other day. No biggie though. I prefer it too, but as far as Haskell is concerned, it's one of those things that's not really worth changing at this stage of its life. Changing the syntactic category of Unicode HYPHEN (U+2010) might still be possible, but someone (with more stamina than me) would have to advocate it. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
On Tue, 2009-12-08 at 10:56 +0100, Deniz Dogan wrote: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. About unicode - if something looks the same it should be parsed the same. I mean - we have already had problem historically with tab vs. spaces (vide Make). BTW. You can always use hello_world. Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Wednesday 09 December 2009 4:54:15 am Maciej Piechotka wrote: You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. About unicode - if something looks the same it should be parsed the same. I mean - we have already had problem historically with tab vs. spaces (vide Make). BTW. You can always use hello_world. hello'world is also an option. I'm a fan of hyphens in names, as well (I use them in Agda, where there's no naming distinction for operators), but I don't really expect it to happen in Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/9 Maciej Piechotka uzytkown...@gmail.com: On Tue, 2009-12-08 at 10:56 +0100, Deniz Dogan wrote: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. I understand. How do GHC extensions work? Would a (hopefully tiny) GHC extension make it possible to use normal hyphens (i.e. those in ASCII) in identifiers? If so, is anyone interested in writing one? -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
A makeshift preprocessor written say in Perl could be used to replace the embedded hyphens with underscores thereby making them synonyms. A list of ways in which hyphens are used in the language will need to be developed so they may be distinguished. You don't want a single line comment sign being taken as containing an embedded hyphen. If done properly it shouldn't cause any problems. It will allow you to side step having to actually modify the language and may be portable across language implementations. I use the C language preprocessor to correct a number of features of the C language syntax that I find ugly.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
Oh yes I forgot. You will also need to map not merely those places where hyphens are used by the language, but also those circumstances where, wondering how to state it abstractly, anyway in string literals and such where substitutions should not occur.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. It's a problem that COBOL solved a long time ago: COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. Haskell already has this problem with ., where we generally need to put spaces around . with the meaning composition and not put spaces around other uses. This is something someone could easily try out by writing a trivial preprocessor to convert hyphens with letters on each side to underscores. See how it works. Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might be nice to have a wee preprocessor that turned lower case letter one _ lower case letter two intolower case letter one Upper case letter two so that I could write take_while and Haskell could see takeWhile. [I'm writing this in MacOS X Mail. takeWhile is underlined in red as a spelling mistake, take_while is not. Maybe they know something...] Here is such a preprocessor. This is meant for people to try out. I don't claim that it's perfect, it's just a quick hack. hspp.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/9 Richard O'Keefe o...@cs.otago.ac.nz: On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. It's a problem that COBOL solved a long time ago: COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. Haskell already has this problem with ., where we generally need to put spaces around . with the meaning composition and not put spaces around other uses. This is something someone could easily try out by writing a trivial preprocessor to convert hyphens with letters on each side to underscores. See how it works. Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might be nice to have a wee preprocessor that turned lower case letter one _ lower case letter two into lower case letter one Upper case letter two so that I could write take_while and Haskell could see takeWhile. [I'm writing this in MacOS X Mail. takeWhile is underlined in red as a spelling mistake, take_while is not. Maybe they know something...] Here is such a preprocessor. This is meant for people to try out. I don't claim that it's perfect, it's just a quick hack. Is there any flag I can pass to e.g. GHC to make it use the preprocessor automagically or do I write my own little hack to apply the preprocessor? -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
The problem that I see with elision resulting in juxtaposition is that it would alter the layout. Each line would not have the same number of characters before and after the makeover. Visual appearance would also be altered. Replacing hyphens with underscores as I originally proposed would alleviate both of these problems. There is also the matter of canonicalization for the purposes of comparing identifiers. Would it be wise for the a version that lacks hyphens be regarded as equivalent to one that does? -- From: Richard O'Keefe o...@cs.otago.ac.nz Sent: 09 Wednesday December 2009 1554 To: Maciej Piechotka uzytkown...@gmail.com Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers On Dec 9, 2009, at 10:54 PM, Maciej Piechotka wrote: You mean to parse a - b differently then a-b? You don't have the problem in LISP as AFAIR you use (- a b) but in Haskell it would be a problem. It's a problem that COBOL solved a long time ago: COMPUTE INCREASED-DEBT = TOTAL-EXPENSES - AFTER-TAX-INCOME. Haskell already has this problem with ., where we generally need to put spaces around . with the meaning composition and not put spaces around other uses. This is something someone could easily try out by writing a trivial preprocessor to convert hyphens with letters on each side to underscores. See how it works. Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, it might be nice to have a wee preprocessor that turned lower case letter one _ lower case letter two into lower case letter one Upper case letter two so that I could write take_while and Haskell could see takeWhile. [I'm writing this in MacOS X Mail. takeWhile is underlined in red as a spelling mistake, take_while is not. Maybe they know something...] Here is such a preprocessor. This is meant for people to try out. I don't claim that it's perfect, it's just a quick hack. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle johndea...@cox.net wrote: The problem that I see with elision resulting in juxtaposition is that it would alter the layout. Each line would not have the same number of characters before and after the makeover. Visual appearance would also be altered. Replacing hyphens with underscores as I originally proposed As long as we're pushing pet peeves: don't line things up vertically then. If you use a newline and add a tab level you can still use layout and not have this problem. You wind up with less indentation too, though occasionally more vertical space. And you can use proportional fonts if you want. And you can use editor indent/dedent commands without the editor having to understand haskell. Etc. My pet peeve is having to lean on the space bar while squinting at the screen because someone wants to line things up vertically. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Interesting point. I'll have to try what you suggested. A proportional font would lessen the need to align things up vertically. It is annoying from a typographical stand point when things are almost aligned, but a tad off and so I must admit that I am guilty as charged. Monospaced fonts encourage this condition. -- From: Evan Laforge qdun...@gmail.com Sent: 09 Wednesday December 2009 1847 To: John D. Earle johndea...@cox.net Cc: Haskell Cafe haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: Allowing hyphens in identifiers On Wed, Dec 9, 2009 at 3:26 PM, John D. Earle johndea...@cox.net wrote: The problem that I see with elision resulting in juxtaposition is that it would alter the layout. Each line would not have the same number of characters before and after the makeover. Visual appearance would also be altered. Replacing hyphens with underscores as I originally proposed As long as we're pushing pet peeves: don't line things up vertically then. If you use a newline and add a tab level you can still use layout and not have this problem. You wind up with less indentation too, though occasionally more vertical space. And you can use proportional fonts if you want. And you can use editor indent/dedent commands without the editor having to understand haskell. Etc. My pet peeve is having to lean on the space bar while squinting at the screen because someone wants to line things up vertically. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Allowing hyphens in identifiers
Deniz Dogan deniz.a.m.do...@gmail.com writes: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax, and have raised the possibility again a couple of times now that unicode hyphens are available, but it wasn't liked at the beginning and hasn't excited much interest since. Why do you want them? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
2009/12/8 Jon Fairbairn jon.fairba...@cl.cam.ac.uk: Deniz Dogan deniz.a.m.do...@gmail.com writes: Has there been any serious suggestion or attempt to change the syntax of Haskell to allow hyphens in identifiers, much like in Lisp languages? E.g. hello-world would be a valid function name. I (among others) suggested it right at the beginning when we were first defining the lexical syntax, and have raised the possibility again a couple of times now that unicode hyphens are available, but it wasn't liked at the beginning and hasn't excited much interest since. Why do you want them? I just like the standard Lisp naming convention better than camel casing and saw someone on #haskell mentioning it the other day. No biggie though. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
