Hacker News Reader

I don't see how "typed/untyped" is a meaningful distinction if you consider "dynamic types" to be types. If the only observable effect of the typechecker in a dynamically-typed language is a runtime error, how do we distinguish an arbitrary source of runtime errors (e.g. "throw" or "error" statements) from a dynamic typechecker? Obviously it isn't the presence of the word "type" in error messages, but what is it? In the presence of the metaprogramming you describe, we can't say it's down to whether checks are inserted automatically either, since non-type dynamic checks may also be inserted pervasively and automatically with metaprogramming.

If Lisp is typed, what's an "untyped" language? One in which the user hasn't done metaprogramming to insert runtime checks? Or is the distinction just about whether it's the end programmer or the language implementor who does the metaprogramming? None of these seem like very useful distinctions.

If it's lispy to actually do a separate typechecking pass, please forgive my ignorance.

Imagine a language where you work with blobs of data and have no restrictions on the operations between them. Like assembly languages. You can add a char* and float and the compiler won't complain. I would call that untyped. A typed language restricts the operations you can perform on blobs of data by classifying them.

A user could build a more restrictive type system on top of an already typed language. The distinction between a type system and an arbitrary source of runtime errors is that a type system has the properties i described earlier, and also it has the cohesion you would expect from it being a "system". A smattering of if statements wouldn't qualify.

That's one way to look at it I guess. Everyone has their own working definitions so I still it's still reasonable if you consider dynamically typed languages to be untyped.

i'd say an untyped (well, weakly typed; every language has some notion of types) language was one like C where you can construct a value of some type, and then treat the block of memory in which the physical representation of that value is stored as some other type.

that said, eric lippert has a good blog post on [defining our terms more precisely before even asking the question](https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...)

There are in fact typeless languages that are neither statically nor dynamically typed, although they aren't particularly relevant nowadays -- BCPL, Forth, and assembly, among others. These languages have only words that hold integer values, with different operators treating the words as an integer, pointer, etc. Those who claim that only static types are worthy of the name "type" would probably consider both dynamically typed and typeless languages to be equally untyped -- dynamically typed languages just support richer semantics on their values, such as storing a "tag" (i.e., dynamic type) in each value.

> Common Lisp, Scheme, and Emacs Lisp all make use of types. They are, to a first approximation [0], all strongly typed and dynamically typed languages.

"Dynamically typed" is a contradiction in terms, at least if one is using the standard technical definition of the word "type". These languages offer runtime checks that have some things in common with a type system (in particular they have some of the same use cases), but they are not types and it is confusing to call them types (even if everyone in computer science agreed to talk about "dynamic types" and "static types" that would still cause confusion, because "static types" are types in the mathematical sense and "dynamic types" are not).

> But the structure of lisp (particularly its homoiconic nature) gives you a calculus over your programs syntax and semantics.

It's more a lack of structure, and a lack of syntax. In many lisps you have less control over syntax than in other languages - any embedded DSL has to be written in Polish notation. (You have reader macros but that's basically just having a program that operates on text strings, which you can do in any language - you can write a C program that preprocesses C source and it's effectively the same thing). I mean sure lisp lets you manipulate a tree of symbols arbitrarily, and then execute that tree with certain semantics. But there are a lot of languages you can do that in. The unique thing about lisp is that your program has to be expressed as a tree of symbols - which yes means that you have a calculus over it, but only by forcing its structure to be trivial. I'd rather have my program expressed as a richer structure, and a language that's powerful enough to manipulate rich structures in a structure-aware way.

> "Dynamically typed" is a contradiction in terms, at least if one is using the standard technical definition of the word "type". These languages offer runtime checks that have some things in common with a type system (in particular they have some of the same use cases), but they are not types and it is confusing to call them types (even if everyone in computer science agreed to talk about "dynamic types" and "static types" that would still cause confusion, because "static types" are types in the mathematical sense and "dynamic types" are not).

That is complete nonsense. Dynamically typed languages have types (many even treat them as first-class objects) and primitive expressions with types assigned to those expressions. What dynamically typed languages let you do is construct and evaluate terms that cannot be typed.

> You have reader macros but that's basically just having a program that operates on text strings, which you can do in any language - you can write a C program that preprocesses C source and it's effectively the same thing

This argument boils down to "you can write a huge compiler in any language you want! it's easy!" There is actually a Lisp meme about it: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

> I'd rather have my program expressed as a richer structure, and a language that's powerful enough to manipulate rich structures in a structure-aware way.

You are confusing program syntax with parse trees. All parse trees look the same ("here is a graph of your program"). You can keep things simple and have a syntax that is context-free, has an obvious mapping to the parse tree, has an obvious interpretation, and has tons of tooling support in hundreds of different tools and editors. Or you can decide that you really really like your whitespace to be very emo and sensitive - just write your own context sensitive parser, roll your own tooling, force everyone to learn it! It's easy!

Re embedded DSL as always Polish notation:

That's not accurate and it doesn't require a reader macro to change it. You do need to state the context in the first position, but any string of symbols after that can be manipulated by a macro. The order at that point is up to the macro designer. See the loop macro as an example.

Well sure, but at that point you're effectively implementing parsing it by hand - which I guess is better than implementing lexing by hand as you would with a reader macro, but not by much. You can take a string of symbols and then does something arbitrary with them, sure, but at that point your language isn't really doing anything for you (and again, you could do that in any language (if the point needs proving: apart from anything else, it's trivial to write a lisp interpreter in most languages) - the difference is that lisp doesn't allow you to do the more structured thing).

In what cases is a `richer' structure better? `Richer' to my ears sounds like `more complicated'. The basic function form of (fun arg1 arg2 ...) or fun(arg1, arg2) is adequate for most things and in lisp when you want to express something that doesn't work well in that form you write a macro to grok some structure (like cond). That all seems very structured to me, and I see no issue with the base structure being trivial. In fact I'd argue that's necessary to achieve a calculus over the code.

Some things just make more sense with infix or postfix notation. Not least of which being mathematical expressions.

I think Haskell handles it really well, where everything is just function application, but identifiers made of symbols apply infix (and there's syntax to switch between them). It's just enough syntax that you can usually structure things how you want, but the rules are still simple enough that it's easy see the tree structure.

Sometimes people go a bit crazy with adding their own operators, but for the most part I think the community is getting over that.

> Some things just make more sense with infix or postfix notation. Not least of which being mathematical expressions.

There are pretty much only four binary operators in modern mathematical notation that make sense infix (addition, subtraction, multiplication, and variable assignment) and only in very short, unambiguous expressions. Pretty much everything else is either prefix (function application, derivatives, summation, etc) or uses special layout formatting rules (division, exponentiation) or both (matrix multiplication).

Even with all of this modern mathematical notation is full of ambiguities. A great short discussion about this is in the preface to Sussman and Wisdom's _Structure and Interpretation of Classical Mechanics_: https://mitpress.mit.edu/sites/default/files/titles/content/... which despite being all about "mathematical expressions" somehow manages to have all of its code in Lisp...

I also recommend reading Munroe's _The Language of Mathematics_ for a better understanding of modern mathematical notation and its weaknesses.

Note also that this is only modern mathematical notation. There is nothing "natural" about infix operators and for most of mathematical history they did not exist (see for example Bashmakova and Smirnova's _The Beginnings and Evolution of Algebra_ or any other book on the history of algebraic notation).

Common Lisp declarations are hints to the compiler that is doesn't have to do as much type checking, and so it can speed things up by omitting type checks, because you the user told the compiler it was safe to do so.

http://stackoverflow.com/a/12677731

...SBCL with certain level of safety declarations does mostly do what you really want though.

In your favorite common lisp. It will result in an error, specifically a `SIMPLE-TYPE-ERROR`.

Just because it calls itself a type error doesn't mean it is. If you don't catch the error until your function actually runs, it's a runtime error, not a type error. Type errors are all caught before the program runs, typically in a compilation step.

You're talking about static types versus dynamic types, not typed vs untyped. A type system that is verified at runtime is still a type system.

Dynamic 'types' are not types, they're tags [1]. Their function, to determine what to do with a piece of data passed to a function at runtime, is common to both so-called statically and dynamically typed languages. The actual function of types, on the other hand, is to prove simple propositions about a program without running it. This feature is unique to statically typed languages.

This is the problem with this entire debate. People act like there are two sides arguing from positions of equal merit. That is not the case. One (static) is a strict superset of the other (dynamic).

[1] https://en.m.wikipedia.org/wiki/Tag_(programming)

Now you're confusing the implementation with the abstraction. Types can be modeled by tags. They can be modeled by trees. Or any other data structure that you can analyze with a program.

>The actual function of types, on the other hand, is to prove simple propositions about a program without running it.

The value of a tag proves something about the program. You're just proving it at run-time rather than compile time.

Which is an artificial distinction anyway, since your static types theorems are being proved during the run-time of your static type checker. All theorems are proven during some run-time.

I am afraid this is true.

The `declare` thing is common lisp is a bit poorly understood in general:

`declare` is not a promise the compiler makes to you to only accept the declared type.

`declare` is actually a promise YOU make to the compiler to only pass the declared type as parameter. Knowing this, the compiler can activate some optimization (it's an integer? i guess i can skip type detection then).

But let's get real:

    * (defun double-integer (x)
        (declare (type integer x))
        (* 2 x))
    
    DOUBLE-INTEGER
    * (double-integer 2)
    
    4
    * (double-integer "qualcosa")
    ;; error here, stack trace omitted

    
    * (disassemble 'double-integer)
    
    ; disassembly for DOUBLE-INTEGER
    ; Size: 37 bytes. Origin: #x10044E4242
    ; 42:       498B4C2460       MOV RCX, [R12+96]                ; thread.binding-stack-pointer
                                                                  ; no-arg-parsing entry point
    ; 47:       48894DF8         MOV [RBP-8], RCX
    ; 4B:       488BD6           MOV RDX, RSI
    ; 4E:       BF02000000       MOV EDI, 2
    ; 53:       488B0576FFFFFF   MOV RAX, [RIP-138]               ; #<FDEFINITION for ASH>
    ; 5A:       B904000000       MOV ECX, 4
    ; 5F:       FF7508           PUSH QWORD PTR [RBP+8]
    ; 62:       FF6009           JMP QWORD PTR [RAX+9]
    ; 65:       CC10             BREAK 16                         ; Invalid argument count trap
    NIL
    * (defun double-integer (x)
        (* 2 x))
    WARNING: redefining COMMON-LISP-USER::DOUBLE-INTEGER in DEFUN
    
    DOUBLE-INTEGER
    * (disassemble 'double-integer)
    
    ; disassembly for DOUBLE-INTEGER
    ; Size: 38 bytes. Origin: #x1004B6CBCC
    ; CC:       498B4C2460       MOV RCX, [R12+96]                ; thread.binding-stack-pointer
                                                                  ; no-arg-parsing entry point
    ; D1:       48894DF8         MOV [RBP-8], RCX
    ; D5:       BF04000000       MOV EDI, 4
    ; DA:       488BD3           MOV RDX, RBX
    ; DD:       41BBA0020020     MOV R11D, 536871584              ; GENERIC-*
    ; E3:       41FFD3           CALL R11
    ; E6:       488B5DF0         MOV RBX, [RBP-16]
    ; EA:       488BE5           MOV RSP, RBP
    ; ED:       F8               CLC
    ; EE:       5D               POP RBP
    ; EF:       C3               RET
    ; F0:       CC10             BREAK 16                         ; Invalid argument count trap
    NIL
    * (double-integer 2)
    
    4
    * (double-integer "qualcosa")
    ;; error here, stack trace omitted

The difference is clear: instead of just performing the multiplication, the generated code must CALL a generic function. With all of the cost of function calling (memory access time and stuff).

For others reading, it's making a call in both cases because "integer" is not a native machine type. Integers are unbounded and include all big integers as well.

The various float types and fixnum (machine register width integer) would compile down to machine code multiplication instructions without function calls, if declared or inferred that the inputs (and output in the fixnum case) are of those types, and the safety option is reduced. (In SBCL)