kbp · HackerTrans

vor 2 Jahrendiscuss

Er, actually

  x = 2
  x = "foo"
  [y] = [3]
  [y] = ["bar"]

Sorry, I didn't re-read the code before translating.

kbp

vor 2 Jahrendiscuss

I'm not sure what you find incomprehensible about the first example. The syntax is pretty standard. The only exotic thing is `$`, which is basically just like putting brackets around the rest of the line. Here's the first example roughly translated to Python:

  def main():
      x = 2
      [x] = ["foo"]
      y = 3
      [y] = ["bar"]
      print(x + y)

Seems about the same level of comprehensibility to me. Is there anything in particular you find difficult to understand?

The second example is expanded out and not how a person would normally write it, but if you're familiar with the basic concepts it's using, it shows why it works very clearly; think of it like assembler.

kbp

vor 2 Jahrendiscuss

It works the same way in Haskell, eg

  main = do
    let x = 2
    let x = "foo"
    y <- pure 3
    y <- pure "bar"
    putStrLn $ x ++ y

which is really the same as

  main =
    let x = 2
    in let x = "foo"
       in pure 3 >>= \y ->
                       pure "bar" >>= \y ->
                                        putStrLn $ x ++ y

So it works pretty naturally where each assignment is kind of like a new scope. If the type system is good, I don't think it really causes issues.

kbp

vor 9 Jahrendiscuss

Pretty-printers are also useful for the times when Lisp is printing code for you to read, for example macro expansions.

kbp

vor 9 Jahrendiscuss

Common Lisp does have syntax for vectors, they're written #(1 2 3). It doesn't have literal syntax for hash tables, but it's a trivial read-macro if you can't live without it (although alists have some other nice properties like easy shadowing/popping of bindings, and the kind of associations you would want to write as literals are generally small enough that their O(n) lookup isn't a problem).

CLTL2 gives a rationale for using #(...) instead of [...] for vectors:

Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.

kbp

vor 9 Jahrendiscuss

> I wonder, does #(* %1) do anything sensible?

It's a 1-argument function, so applying it to 2 arguments would give an error. Minus the arity error, 1-argument * is an identity.

kbp

vor 9 Jahrendiscuss

There's nothing preventing you from manually doing that when you type the code, but editors and pretty-printers won't know about it. Special-casing them to have "if the car of a list is cond, or this vector was preceded by let, ..., then every second element gets extra indentation if it's on a different line" vs just using the regular list formatting rules just squicks me.

kbp

vor 9 Jahrendiscuss

I agree, the decrease in editor-friendliness is really frustrating, coming from Lisp. The lack of parens around cond clauses is also annoying to me, because it makes it so that you can't really insert a newline after a predicate for legibility, since it makes the then-part flush with the other predicates (and similarly for let bindings).

comments