Hello, 2010/2/26 Terje Norderhaug <te...@in-progress.com>
> On Feb 25, 2010, at 7:59 PM, Sean Devlin wrote: > >> As to you question about editors, I know that it's possible to adapt >> emacs clojure-mode the change colors based on a regex. That's how it >> knows to color something "pink" for a fn in clojure.core, and green >> for a fn in the standard library (e.g. clojure.walk). You'll have to >> make your own customizations, of course. >> > > Syntax styling is better based on the meta-information of symbols rather > than on whether the name of a symbols fits a pattern. Hence it would be a > mistake to institute syntax conventions for symbols and clutter the code > just to facilitate styling in editors. > Maybe ideally, but to do so an editor would have not only to read the source code, but also to execute it, as soon as the meta-information on the symbol is added by a macro call. Not all editors can do that currently. (I know of ccw for coloring differently words with the same name as core symbols of macro nature from the others. Not sure for other editors). > > -- Terje Norderhaug > > On Feb 25, 10:50 pm, joshua-choi <rbysam...@gmail.com> wrote: >> >>> Ah, yes, it is a. (The only thing that I anticipate a computer would >>> use this for is different syntax highlighting. Actually, can any >>> Clojure editors change symbols’ colors based on if they match a >>> pattern like *a*?) >>> >>> Because Daniel Warner and Jarkko Oranen both said they think >>> underscores are undesirable, I suspect that a lot of other Clojure >>> users feel the same too. Right now, I’m thus leaning toward using - >>> vector-. I’ve just tried replacing all rule symbols in one of my files >>> with -blah-, and it actually looks a little pretty. If I don’t hear >>> any other good suggestions, I think I’ll use circumfix hyphens, then. >>> >>> On Feb 25, 8:31 pm, Sean Devlin <francoisdev...@gmail.com> wrote: >>> >>> >>> >>> Hmmm... maybe I misunderstood your point. Is the intent of your >>>> naming conventions: >>>> >>> >>> a. Something that is human readable but does not affect the execution >>>> of code? Examples include placing I in front of interface names, and >>>> A in front of abstract class names. >>>> >>> >>> b. Something that other code will use to infer behavior? Examples of >>>> this include JUnit 3.8 & the get/set Java Bean convention. >>>> >>> >>> If it's a, I made a mistake & my comments don't apply (as a matter of >>>> taste I like suffixes). If it's the behavior version, I think that a >>>> special macro is in order (e.g. deftest) >>>> >>> >>> Sean >>>> >>> >>> On Feb 25, 10:22 pm, joshua-choi <rbysam...@gmail.com> wrote: >>>> >>> >>> Could you explain more what you mean? For instance, how are macros >>>>> related to these questions? This just has to do with informal naming >>>>> conventions, in the same matter as *e or *print-dup*. Are you talking >>>>> about that it’s possible for naming conventions to interfere with >>>>> macros that interpret symbols abnormally if they’re named a certain >>>>> way? >>>>> >>>> >>> Now, I’ve considered just not using any characters to set apart rules >>>>> completely, but that’ll bring me back to my original problems. The >>>>> only disadvantage I can think of to using a convention is that it >>>>> might make code that use rules more noisy...but I think that’s >>>>> preferable to having to recall what a rule is called if it conflicts >>>>> with another symbol—which is really common with my rules. What >>>>> notation do you all think is the least ugly? >>>>> >>>> >>> On Feb 25, 7:32 pm, Sean Devlin <francoisdev...@gmail.com> wrote: >>>>> >>>> >>> I think using a naming convention isn't a good idea, especially when >>>>>> you have a rich macro system like Clojure. I'm actually going to be >>>>>> talking about using a reference to handle things like this in my next >>>>>> episode. For now, you can take a look at my definference macro here: >>>>>> >>>>> >>> http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/ >>>>>> master/s... >>>>>> >>>>> >>> Hope this helps, >>>>>> Sean >>>>>> >>>>> >>> On Feb 25, 8:59 pm, joshua-choi <rbysam...@gmail.com> wrote: >>>>>> >>>>> >>> Yeah, I don’t really like the underscores either. But I have to work >>>>>>> with the set of currently allowed non-alphanumeric symbol characters >>>>>>> (*, +, !, -, _, and ?, according to clojure.org/reader). >>>>>>> >>>>>> >>> There’s actually two different questions here—I’d love for other >>>>>>> people to bring in their input. >>>>>>> >>>>>> >>> I need to set apart “rules”, a certain type of object, from other >>>>>>> kinds of Clojure objects. ("Why do you even need to do this?" people >>>>>>> ask. Because I really want to graphically set them apart in the >>>>>>> programmers mind. And also, rules often shared names with objects >>>>>>> that >>>>>>> they were representing: it was difficult to remember string-char-r >>>>>>> vs. >>>>>>> string-char in functions, for instance. It was always a big pain. I >>>>>>> think it will be worth it.) >>>>>>> >>>>>> >>> Question 1: Of the allowed characters, which would be best to >>>>>>> distinguish rule symbols from other symbols? >>>>>>> >>>>>> >>> * can be confused with the REPL vars (*1, *e, etc.) and re-bindable >>>>>>> vars. >>>>>>> + may be a better choice, though in the other Lisps it already >>>>>>> indicates constants. >>>>>>> I don’t think ! and ? are good at all, because they really stand out >>>>>>> to me to mean destruction and querying respectively. >>>>>>> - is apparently used only once in the standard libraries: in defn-. >>>>>>> Maybe it would be a good choice. >>>>>>> _ is ugly, but it’s not used at all, so that’s good. Well, except >>>>>>> when >>>>>>> used on its own: “_”, for useless bindings. >>>>>>> >>>>>> >>> I’m leaning toward +, -, or _. >>>>>>> >>>>>> >>> Question 2: Prefix, suffix, or circumfix? >>>>>>> >>>>>> >>> +vector, vector+, or +vector+? -vector, vector-, -vector-? Or >>>>>>> whatever. Don’t forget, I’m deciding this for my parser rules >>>>>>> library. >>>>>>> “vector” means a rule that can parse strings representing vectors. >>>>>>> >>>>>> >>> Could everyone give me their opinion? Which annoys your taste the >>>>>>> least? I still have time to change the style in my library, and I’d >>>>>>> like to hear from as many people as possible. >>>>>>> >>>>>> >>> On Feb 25, 3:16 pm, Jarkko Oranen <chous...@gmail.com> wrote: >>>>>>> >>>>>> >>> On Feb 25, 12:17 am, joshua-choi <rbysam...@gmail.com> wrote: >>>>>>>> >>>>>>> >>> When it comes to distinguishing certain types of symbols from other >>>>>>>>> things, should one use prefixes or suffixes? >>>>>>>>> >>>>>>>> >>> Whichever makes more sense, of course. :) >>>>>>>> >>>>>>> >>> Example: naming tests with clojure.test/deftest. If you distinguish >>>>>>>>> your tests’ symbols at all, do you do “t-addition” or “addition-t”? >>>>>>>>> >>>>>>>> >>> Name tests descriptively. Putting them in their own namespace helps >>>>>>>> too. If there's absolutely a need to distinguish them from >>>>>>>> non-tests, >>>>>>>> I would prefer '-test'. Abbreviating it just makes it noisy. >>>>>>>> >>>>>>> >>> (I need to know what the standard is, if there is any, because I need >>>>>>>>> a way to distinguish a certain type of symbol—those that represent >>>>>>>>> “rules”— in my libraries. I’m using an underscore suffix right now, >>>>>>>>> like “vector_”, which means “vector-rule” But “_rule” might be >>>>>>>>> better, >>>>>>>>> or even “_rule_”, though the last one might be overkill. In the >>>>>>>>> past, >>>>>>>>> I’ve used “vector-r", but I don’t like that now.) >>>>>>>>> >>>>>>>> >>> I personally find underscores offensive, but... Some logic DSLs use ? >>>>>>>> foo for variables, maybe you could have something similar for you >>>>>>>> rules. Or you could name them using angled brackets (eg. <vector>). >>>>>>>> When it comes to naming, you just need to be consistent. And avoid >>>>>>>> underscores, please :P >>>>>>>> >>>>>>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- Terje Norderhaug > te...@in-progress.com > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
