Hacker News Reader

Comment by skissane | Hacker News Reader

> That said, Common Lisp is weird. What I find particularly jarring is that functions and variables live in different namespaces:

Lisp-2s aren’t the only languages in which functions and variables are different namespaces - the same is true of PHP, Perl, Bash, etc. But the later mark the distinction through syntax - variables start with a dollar sign, functions don’t. I think there is something to be said for that approach, compared to the Lisp-2 way it is easier for beginners to understand, and it is instantly obvious whether a symbol is a variable or something else like a function, while also avoiding the Lisp-1 problem of built-in function names clashing with those of popular variable/argument names. I wonder why there are so few Lisp-like languages which adopt the “sigil solution”. (Common Lisp does have sigils, such as :keywords, but not for variables.)

View on HN

A standard practice in Common Lisp distinguishes special variables by "earmuffs": the symbol names of special variables, by convention, start and end with asterisks. No requirement for this exists in the language definition, but just about everyone follows it.

It would be really annoying to have the same sort of de facto requirement for function names. Making the programmer use funcall or apply when calling a function value is much less intrusive, especially since CL idiomatically doesn't have the tail call fetish that Scheme seems to have.

That's to distinguish global variables though.

Common Lisp doesn't have "global variables", it has "special variables", which are subtly different.

Although Common Lisp is called Lisp-2, there are actually many more namespaces... I think I counted 5 or 6 the last time I tried. But it is pretty sensible to keep functions in a different namespace. For instance, it allows you to: (let ((let '`(let ((let ',let)) ,let))) `(let ((let ',let)) ,let))

That's sensible? I do not think that word means what you think it means...

I mean, yes, having functions in a different namespace may be sensible, or at least defensible. That example is ridiculous.

It's like `make make make make`. But it is nice that in CL you don't have to jump through hoops on common words that happen to be function or package names. You have a list and no meaningful name? Call it `list`:

  (defun some-algo (list ...) ...)

Sure you can abuse this, everything can be abused. But I'd rather risk an asshole doing that `let` thing (which wouldn't make it past code review) than have more name collisions and naming contortions to avoid them. If the language at least warned on renaming it would be helpful, but then you get things like Go. When I was learning it I accidentally overwrote some built-in function (I don't recall which one, it wasn't actually `make` like in this demo):

  package main
  func main () {
      make := 10
      aMap := make(map[int]string) // this is now an error
  }

I wish I could remember what it was, it was a reasonable name in context (unlike `make` above). But it had a similar effect and a similar strange error. The error is at the function call site, which is technically correct because you're trying to use an `int` (here) as a function. But `make` (above) and similar functions should probably get a warning emitted when you redefine them, at a minimum.

If Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo, might as well let let let let let.

In seriousness I like the ability to make such distinctions even if it can be a huge footgun.

In practice it is not a footgun at all! If you use Lisp, you can tell what's a function and what's a variable by position - functions are always first in a list, variables - never, (except in bindings)... etc.

There is this thing we call humor. Try running the example!

Reply on news.ycombinator.com