The best kittens, technology, and video games blog in the world.

Monday, June 04, 2007

Some thoughts on RLisp style

Triple Self Portrait by Monkey & Timmy from flickr (CC-NC-SA)
Established languages tend to have more or less official style guides. Here are links to a few random style guides - Ruby, Python, Perl, Common Lisp, Smalltalk [PDF]. Style guides would be pointless for languages like C and Java, as coding in them requires utter disregard for aesthetics.

RLisp is still too young for a definite style guide, but I have a few tips. They're not "binding" in any way, not even for patch submitters for RLisp, and I am likely change my mind many times before 1.0 (if there will ever be 1.0).

  • Use fn/hd/tl instead of lambda/car/cdr
  • Use 2-space indentation. Or maybe 4-space indentation. In any case don't use tabs.
  • Function and variable naming should mostly follow Ruby and Scheme style:
    • Functions which return boolean values should end with ? , like (empty? obj).
    • "Dangerous" functions should end with !. Like sort for returning sorted container versus sort! for sorting it in-place.
  • Message passing should usually be done with [obj method arguments] instead of (send obj 'method arguments). In cases where it's possible to use either a message send [a == b] or a function call (eq? a b), pick your choice.
  • I consider strings of car/cdrs a bad style. Usually you can pattern match, or use something like (nth a_list index), or (ntl a_list index), or [a_list get index], or [a_list get [index .. -1]]. I think any of these look better than a string of cars and cdrs.
  • RLisp doesn't support non-ASCII (that is UTF-8, other character sets would definitely not be supported) characters in identifiers. I'm not decided yet if it would be a good idea to support them or not.
  • There's no need to use excessive indentation. Because of different (let ...) semantics RLisp programs can often be indented a lot less than Scheme/Common Lisp programs.
  • RLisp doesn't do tail call optimization yet, and Ruby stack isn't that big. That means Scheme-style excessive recursion is not a good idea. It should be fixed in the future.
  • There's a simple code formatter for RLisp, but I don't think you should trust it too much.
  • I sometimes place )s and ]s on their own lines, and sometimes together with the last expression line. A rough guide would be - place ) on its own line if you'd use end in Ruby, and place it together with expression line if in Ruby you'd use }. That's not very helpful, as end vs } is a matter of personal style. Here's an example from the RLisp test suite, which might make it a bit more clear. Only ) for (test-suite ... got its own line, and I think it would look weird if it didn't. Other )s don't really need own lines.
(test-suite Text_Processing
(test parse_ip
(assert (parse-ip "1.2.3.4") == '(1 2 3 4))
(assert (parse-ip "64.233.183.104") == '(64 233 183 104)))
(test parse_ip_2
(assert (parse-ip-2 "1.2.3.4") == '(1 2 3 4))
(assert (parse-ip-2 "64.233.183.104") == '(64 233 183 104)))
(test parse_ip_3
(assert (parse-ip-3 "1.2.3.4") == '(1 2 3 4))
(assert (parse-ip-3 "64.233.183.104") == '(64 233 183 104)))
)

A more definite RLisp style will only develop if a lot more RLisp code is written, preferably by a lot of people other than me.

2 comments:

Jason Grossman said...

"RLisp doesn't support non-ASCII (that is UTF-8, other character sets would definitely not be supported) characters in identifiers. I'm not decided yet if it would be a good idea to support them or not."

You'd better support UTF-8 if you want RLisp to outlast the dominance of English as a world language :-)

taw said...

I don't know of any programming language which successfully adapted non-ASCII characters. In any case it'd be a pretty easy thing to change.