#lang typed/racket ;; Using higher-order occurrence typing (define-type SrN (U String Number)) (: tog ((Listof SrN) -> String)) (define (tog l) (apply string-append (filter string? l))) (tog (list 5 "hello " 1/2 "world" (sqrt -1)))

One of definitive features of Lisps is heterogeneous lists, upon which other features, such as code-generation and hence macros has been built.

All the cleverness of static typing falls apart with heterogeneous lists. That's why we don't have them in Standard ML or Haskell. So, in Lisps we trade static typing for power and flexibility of layered DSLs based on special forms (advanced macros). typecase macro, CLOS, structure-based pattern-marching modules are examples of such DSLs. Strong typing is good-enough.

This is just my opinion, of course. Lisp has been evolved with its own way. Like famous quote form evolutionary psychology (or biology?) goes - Everything is the way it is because it got that way.

http://karma-engineering.com/lab/wiki/Languages

http://karma-engineering.com/lab/wiki/Bootstrapping2

See HLists (e.g. https://hackage.haskell.org/package/HList) for heterogeneous lists in Haskell. The techniques for implementing these are relatively (last 10 years or so).

As long as a list could contain anything then it could be mapped to another list of anything (a list of symbols, numbers, etc.) Or a value. Basically, we could say a pointer or a list of pointers, which by definition could point to any kind of a type-tagged value.

Types a-la

   (* -> *) -> [*] -> [*] 

Moreover, as long as there is no difference between a pointer to a list and pointer to a value (these are just bindings of symbols to type-tagged values) we could have procedures of type

   * -> * -> * 

So, all the values have type-tags. Add NIL and T, structural types such as arrays or structs, and you will get a crude type hierarchy of a Lisp.

Our lists aren't sets (homogenous) so all the typing based on Set theory is of no use.

Second paragraph is about heterogeneous lists.

You can have heterogeneous lists in Haskell. What you don't have is open heterogeneity as in Scala (where List[Any] is a valid type). You have to decide how much heterogeneity you'll allow a priori, like so:

    data MyLang = Number Double | Str String | Sexp [MyLang] | Fn (MyLang -> MyLang)
    expr = Sexp [Str "+", Number 5, Number 7]

With advanced uses of typeclasses, you can buy back a lot of the heterogeneity and code-level expressiveness of dynlangs (at the expense of dealing with complicated type signatures, language extensions, and scary-sounding concepts like "monad transformers"). There's little that you "can't" do in Haskell, insofar as you can build an arbitrary dynamic language within it. Haskell just requires you to decide a priori how much heterogeneity and reflection you want, and makes it hard to change that on the fly.

What I like about Haskell is how much discipline it demands. I don't expect to see the static vs. dynamic debate resolved within my lifetime, because those families of languages excel in different ways, but I like the intellectual exercise of having to make sure my design is sound before it even compiles. Static typing isn't "a silver bullet" and only catches ~30-50% of errors if used naively, but if you know how to use it and have a good design sense, you can bring that number way up (90%?). If your goal is to write robust code, you spend as much time thinking about testing in Haskell as in Python. The advantage of "the Haskell Way" is that most of those unit tests don't exist in code; they're implicit in the type system, or very tersely specified (with superior coverage) in QuickCheck.

What we want in a language, loosely speaking, is O(log n) added work ("accidental complexity") in terms of the size of the problem/functionality achieved. We can never get rid of that, but we'd like it to be sublinear as a function of what we're accomplishing. (Since our goals are most often subjective, the big-O notation is used loosely.) Inexpressive languages throw O(n) accidental complexity at you, but poor use of expressive languages throws O(n^2) or worse (in fact, potentially incomputably worse, since arbitrary code comprehension is formally undecidable) maintenance complexity at you. I don't know if Haskell is at the O(log n) level, for a priori accidental complexity, yet. But it's definitely sublinear (maybe O(n1/3)) and, in the real world, that's good enough. (If you program for the business, there's plenty of "other" complexity that is O(n) or worse, and more infuriating than any technical challenge.)

This is very powerful "mantra" indeed, and millions "believe". I am not trying to say that The Haskell Way is worse or better (Java way is worse indeed), all I am trying to say is that, in my opinion, everything "interesting" in Lisps begins with an ability to define a new special form as a macro to extend the language.

Arc language and this site championed this approach to implement complex systems as layers of DSLs embedded in Lisp - the code of arc.arc and news.arc is indeed layers of macros built out of another macros, in accordance with principles described in On Lisp book.

This is in some sense an opposite to The Haskell Way you have described above. It is not better or worse, it is very different and has its own beauty and elegance (and Haskell has its own, especially these either-of and one-of types).

You see, as long as a tiny doing-a-single-thing Arc procedure or a marco (the basic building block) runs correctly in REPL, it will run correctly later - as long as it is free of side-effects - no unit test required (it is not Python or Ruby).

The real difference, is that in Haskell you cannot pass a wrong arguments to a procedure - you will get a compile-time error, while in Arc you could and will get a run-time error.

"Lisp people" it seems, "believe" in really quick prototyping, exploratory programming (on-the-go), like PG named it, while "Haskell people" believe in careful planning in advance and "safety" of double-checks.

I would say that in reality, in mountains, for example, planing in advance almost never worked - you will never cover all the possible scenarios, but making decisions quickly, on the go, adapting to constantly changing conditions of high altitude saves lives and leads to the summits. This is why, perhaps, I am "Lisp person". For me, "safety" comes from flexibility (ability to change/respond quickly), not from any "guarantees".

Deep thought and planning can help you in either language - but they're more required when you can't see what breaks with changes.

Depends on how big that constant factor is. Most systems aren't going to take the limit N -> Infinity.

In business, you tend to have three relevant scaling cases: better-than-linear ("synergy"), linear, and worse-than-linear ("congestion"). "Bad" (inexpressive) languages tend to be non-synergistic in capability/delivery of features and congested in terms of accidental complexity. "Good" languages, if used competently, go the other way.

But the experiment shows nicely how little you need to bootstrap something lispy.

  * (defun foo (x) x)

  FOO
  * (declaim (ftype (function (fixnum)) foo))

  * (defun bar (y) (declare (string y)) (foo y))
  ; in: DEFUN BAR
  ;     (FOO Y)
  ; 
  ; caught WARNING:
  ;   Derived type of Y is
  ;     (VALUES STRING &OPTIONAL),
  ;   conflicting with its asserted type
  ;     FIXNUM.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ; 
  ; compilation unit finished
  ;   caught 1 WARNING condition

  BAR

  * (declaim (ftype (function (fixnum)) qux))

  * (defun qux (z) (car z))
  ; in: DEFUN QUX
  ;     (CAR Z)
  ; 
  ; caught WARNING:
  ;   Derived type of Z is
  ;     (VALUES FIXNUM &OPTIONAL),
  ;   conflicting with its asserted type
  ;     LIST.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ; 
  ; compilation unit finished
  ;   caught 1 WARNING condition

  QUX

http://www.lispforum.com/viewtopic.php?f=2&t=191

TL;DR is that many CL implementations will check types at compile time, but for appropriate speed and safety settings, they will also generate code that checks types at runtime, too.

  char *foo(char *bar) {
    return bar;
  }
  
  int main(int argc, char *argv[]) {
    foo(1);
    return 0;
  }

  $ cc test.c 
  test.c:6:7: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'char *' [-Wint-conversion]
    foo(1);
        ^
  test.c:1:17: note: passing argument to parameter 'bar' here
  char *foo(char *bar) {
                  ^
  1 warning generated.

Also: https://github.com/clojure/core.typed

But that's possible (and available).