Ed, How about just escaping class names all the time?
TUPLE: foo a b ; \ foo new That way it's clear that foo will not execute as a word and we won't have to generate any new sytnax like Foo or foo%. : foo "lol" throw ; Now we original usage of foo will still work. In general, I prefer this kind of preventative coding. You could do the same for symbols -- I know it's redundant, but I love that the code is robust if the symbol name is ever used as a word name and I don't mind reading an extra backslash if it makes code easier to change in the future. Also, \ already exists. I don't want to have "syntax creep" because it would take away from Factor's simplicity. Doug On Nov 28, 2008, at 4:30 PM, Eduardo Cavazos wrote: > Hello, > > One of the reasons I'd like to have a convention for class names is > because without one, classes just look like normal words and as a > result, class names are sometimes shadowed by normal words. > > This generates a list of classes who's names are shadowed by words: > > classes > [ tuple-class? ] filter > [ symbol? not ] filter > [ def>> \ throw swap member? not ] filter > [ name>> "#" head? not ] filter > [ name>> "_" head? not ] filter > natural-sort . > > I've filtered out error tuples (which are auto-generated by ERROR:) > and a bunch of internal words used by the compiler. > > In my base image there's fifty such classes. > > I'm quite fond of the <abc> convention from CLOS, Dylan, and a bunch > of Schemes. Alas, that convention is already used in > Factor. Unfortunately the convention is not well specified. I.e. <abc> > doesn't mean that an object of class 'abc' is created. It can mean > alot of stuff. It would have been nice to respect that tradition. > > Slava has proposed moving away from generated class predicate > words. (Not sure if that's still planned.) I.e. when you do: > > TUPLE: abc ; > > An 'abc?' word wouldn't get created. Instead you'd do: > > abc instance? > > (don't be alarmed by the long 'instance?' word. Perhaps we can use > 'is?' or 'isa? etc). > > If that change happens, uniform class names will help. With some of > the classes shadowed, you'll inconsistently see: > > \ abc instance? > > or > > abc instance? > > In "the beginning", class words weren't used directly very often. But > over time we've moved in a direction where they are. I.e. we have > 'boa' and 'new'. > > I believe that if Factor were in widespread use, folks would > pick conventions for things like class names. If we don't have one to > offer, there'll be non-standard set of conventions floating around out > there. > > For my own code that I check into the mainline, I'm leaning towards > one > of these: > > %rectangle > > Rectangle > > I'm open to suggestions on a convention. > > For my really personal code, I might still use '<abc>'. But I can > understand that it's an abrasive choice for stuff that alot of other > folks might read. > > Ed > > PS: Here are some other off the wall convention possibilities: > >> pos< > > |pos| > > /pos/ ! too close to traditional regular expressions > > \pos\ > > <-pos-> > > pos% > > /pos\ > > \pos/ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Factor-talk mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/factor-talk ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
