Hacker News Reader

Comment by abhinav22 | Hacker News Reader

You get used to it pretty quickly. Just need a bit of practice.

I used to say that proper indenting helps readability but these days I have departed from the standard indenting and do my own thing.

That said, this guide on formatting lisp is very useful IMO if you want to learn to read lisp code better:

https://link.medium.com/idMRZk93Fdb

I actually wrote it, but now I don’t follow many of its principles :D perhaps because I got a deeper understanding of it. Check it out if and see if it helps

View on HN

What is the reason why Lisp allows you to use the hyphen for an identifier name?

This overloads the subtraction operator. And it makes the code very confusing to read.

And plus, Lisp also uses the hyphen as the subtraction operator.

It doesn't. Common lisp is a lisp-2, which means that there are 2 namespaces: one for functions and one for variables. (Technically there are quite a bit more, but that's beside the point.)

Which means that you can do this:

  (let ((- 5)) ; bind the '-' variable to 5
    (-         ; call the '-' function
      -        ; on the '-' variable
      17))     ; and the number 17
               ; this evaluates to -12

You can. But you shouldn't :-)

this is also possible...

  CL-USER 5 > (- 1 2 3 4 (third -))
  -10

This is a non-issue for all Lisps, not all of which are Lisp-2.

Your code doesn't seem like a very good idea, even though it is legal.

> Your code doesn't seem like a very good idea

Why not?

I usually use an 'anaphoric if' macro that binds - to the given value. It seems more clearly 'special' than a name like 'it'—which seems like the canonical name—closer to the perl/raku $_.

That's more of an issue for languages that use infix notation for operators. Lisp uses prefix notation, that's why

a-b

is not a problem. As a practitioner, you don't get confused at all when you encounter a variable name that contains a dash, because you don't even read it as a subtraction. Your brain is trained to match only the

    (- a b)

pattern for that.

C programmers on Unix somehow don't get confused by the POSIX shell:

  $ foo-bar()
  > {
  >    echo 42
  > }
  $ foo-bar
  42

or Make:

  OBJ_COMMON := common.o

  OBJ-$(CONFIG_FOO) += foo.o foo-tab.o
  OBJ-$(CONFIG_BAR) += bar.o

  OBJS := $(COMMON_OBJS) $(OBJ-y)

even though foo-bar and OBJ-y look like a C subtraction.

C programmers on Unix came up with this stuff themselves.

in a more traditional sense Lisp does not have operators by default. Operators which have a special syntax (infix ...) and precedence rules. Operators like + and - are written as normal functions -- thus these characters are allowed in function names. Actually more characters incl. whitespace and returns are possible -> one can escape characters in symbols or whole symbols.

There are a bunch of conventions for naming things:

  +foo+     ; convention for naming a constant
  *foo*     ; convention for naming a special/global variable
  foo-bar   ; convention for a compound name

Other programming languages use FooBar, foo_bar or similar, instead of foo-bar.

More naming conventions in Lisp are collected here:

https://www.cliki.net/Naming+conventions

Thanks for the link - very useful

In my non verified view, it’s easier to type with dashes and looks better than camelCase. Also spaces are used as delimiters, so can’t use them.

It’s all preference though. I used to like camelCase when I was learning Java, now I like hyphens. I program both in JavaScript and Lisp and have no issues with both

I may be wrong, but one of the benefits of NOT allowing hyphens in names in languages like JavScript is code can be minified (you can remove spaces and use operators as delimiters, which only works if “-“ only stands for subtraction).

I think. Haven’t verified this, but the thought came to my head the other day.

There is not a great need to minify many languages other than Javascript. The way I see it, the need arose mainly because it took such a long time to agree on a bytecode representation of JS.

I would say that Javascript was not at all designed to be delivered the way that it is. The design characteristics of JS that allow minification, I think are just happy coincidence.

Consider that Javascript early on was marketed as a companion to Java (applets). Java, of course, used a bytecode representation to deliver programs on the Web from square one. If Javascript had been designed for efficient delivery of "compiled" programs, bytecode would have been the obvious choice.

I think my point is, languages are not generally designed to minify well, because minification is the technique of last resort for efficient delivery.

Thanks - this helps expand my knowledge on this topic :)

I think a much bigger consideration would be the utter difficulty of reading something like this:

  a-b - a - b

Even though I personally love hyphenated-identifiers in Lisp, I would not want them in any language that has infix operators, whether it cares about minification or not.

I think it’s getting used to it, for example I would never confuse a-b with a - b, but that’s because I’m used to using hyphenated identifiers.

I can see others (beginners) getting confused, but it’s something they will very quickly get over. For example I didn’t know JavaScript was case sensitive, but it was a very quick adjustment when I learnt this

In some infix syntax, one might then need to escape characters. Example 'infix' for Common Lisp:

  (let ((foo-bar 29))
    #i(   foo\-bar - 3 * foo\-bar    ))

I refer to long symbol names a lot more often than I subtract things. If I could have it in Python or Java I'd be happy, using - is just nicer than _ or camelCase. Using spaces in pipes |like this| is nifty sometimes too. I'd be willing to accept warnings/compiler errors on the seemingly never-in-practice occasion when the compiler notices that all 3 of 'a-b, 'a, and 'b are bound symbols and I need to use a more explicit expression (like the escaped '- in lispm's example, which is how the cmu-infix library solves the problem).

On the other hand, some advice from Chuck Moore (found in Thinking Forth) that I think about sometimes:

"There are diverging programming styles in the Forth community. One uses hyphenated words that express in English what the word is doing. You string these big long words together and you get something that is quite readable.

But I immediately suspect that the programmer didn’t think out the words carefully enough, that the hyphen should be broken and the words defined separately. That isn’t always possible, and it isn’t always advantageous. But I suspect a hyphenated word of mixing two concepts."

That could be English written in ASCII, with the same hyphen serving as a dash:

Example sentence:

"Examples of sado-masochism - such as Java-influenced languages - are rampant in the field of computing."

Quite readable.

> What is the reason why Lisp allows you to use the hyphen for an identifier name?

Lisp has only ~7 special characters: (, ), #, ', ", ` and wite-space. All others are valid as part of an identifier, alone or together. So for example "---" is a valid Lisp identifier, just as much as "aaa".

There is no subtraction operator in lisp. "-" is simply the name of a function in the standard library that implements addition (technically, it might be a special form and not a function, but that's beside the point).

> This overloads the subtraction operator. And it makes the code very confusing to read.

a-b-c in Lisp is unambiguously an operator. Subtraction would be (- c b a) - you can't really confuse these two.

Subjectively, I happen to think that hyphenated-names are much easier to read and type than camelCase or snake_case. I think most of the world agrees as well, since this is one of the more common typographical roles of the hyphen: joining words, such as 'pre-approved' or 'ill-defined'.

Haven't seen anyone mention that "-" is not a function at all. it is a symbol. A symbol which bound to the function which does subtraction.

Users are free to redefine it outright, or to redefine it it multiple ways in different scopes of their application. (Not sure how wise this would be, but not really the point ...)

Not to be offensive, but the question as written seems to imply looking at lisp from preconcieved notions from other languages that probably don't make sense to carry over in understanding lisp.

Reply on news.ycombinator.com