Hacker News Reader

Comment by krautsourced | Hacker News Reader

Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work?

  let shoe = 5;
  let size = 3;
  let shoe-size = 10;
  shoe-size := shoe-size;

Now what? Is shoe-size 10 or 2?

View on HN

It would work, and the value would still be 10.

I suggest not characterizing this as "allowing operators in variable names" any more than you'd call it "allowing keywords in variable names" that in most languages you can have variables called "life", "athena", "door_count" and "ended" even if "if", "then", "do" and "end" are keywords.

(Does C "allow operators in other operators" because it has both "+" and "++"?)

Rather: in Dylan, more characters than in (say) C are treated as ordinary constituent-of-identifier characters, with the consequences that (1) you can have things like hyphens in your names and (2) you more often have to use actual whitespace to delimit operators. ("shoe-size := shoe - size".)

This is traditional in Lispy languages, in most of which #2 isn't much of a drawback anyway because of the prefix syntax (in C you can say "a=b-c" if compactness is important to you, but obviously you're not going to write "=a-bc" in a prefix language or "bc-a=" in a postfix one). Dylan is unusual in preferring #1 over #2 despite using infix syntax.

White space is required around operators. This allows the names of bindings (variables, methods or whatever) to be very flexible. Things that represent a boolean can end in '?'. Operations that mutate can end in '!'. In the Objective C bridge that I'm working on, I make use of '/' like: 'objc/class-responds-to-selector'.

Type names are typically enclosed in '<...>' like '<integer>' (but that's just a convention used everywhere).

Ah, ok, I had not seen the part about the mandatory whitespaces. I still think it has the potential to confuse, so if I were to write in languages that allow dashes, I'd probably still avoid them where possible (can't see the advantage over using underscores instead). Anyway, thanks for the info.

Having plenty of experience both with languages that do and do not allow "operators" in variable names, it's not actually confusing in practice. You quickly learn that whitespace is very significant in those languages, and then you read them differently. This isn't any different than indentation in Python, line breaks in Ruby, or sigils in C++.

I haven't really programmed in Lisp or Dylan, but the code I read certainly seemed the better because of the punctuation in function names. It gets denser, but stays readable. A question mark signals 'returns boolean' just as strong as a "Is" or "Has" prefix, and there AFAIK is nothing in other languages that signals "modifies its arguments" as strong as a ! suffix.

I also find that Dylan's convention of using brackets in class names rapidly grows on you. But maybe that requires working in Forth as a warming up.

And of course, hyphens not only look better than underscores, they are easier to type, too :-)

10. and those aren't operators, they are hyphens :-)

Hyphens get reused to mean negation and subtraction, but they aren't operators everywhere.

If that surprises you, you haven't used enough Lisp or Forth.

See http://opendylan.org/documentation/intro-dylan/expressions-v... for more info (note the naming conventions. Those will quickly learn you to discriminate operators from characters used in symbols)

If they allow dashes in names, then they probably tokenize binary operators using mandatory whitespace.

Reply on news.ycombinator.com