[jhuni]

I like having access to mathematical semantics, simple algebraic rules, and all the other things you mentioned but combining these features with a non-homoiconic syntax spoils the whole thing for me.

> Not only is the community particularly nice and welcoming, it's also special in not being afraid of a bit of math.

The Lisp community has never been afraid of math. John McCarthy had a PHD in mathematics and the earliest computer algebra systems were developed in Lisp. The Macysma computer algebra system (now developed as Maxima) predates Haskell by decades.

> Haskell has an incredible but also surprisingly simple type system. You can't just ignore that. There is nothing in lisp--not even typed Racket--that even comes close to Haskell's type system.

The most important thing for me is having the ability to describe cardinality (especially in terms of machine bits such as 2^8, 2^16, etc) and enumerations (like the ASCII character encoding). What aspect of Haskells type system is that Lisps need to "come close to"?

[tikhonj]

My point with math is that Haskell libraries and code use mathematical abstractions (like various sorts of algebraic structures) far more than lisp; I was not taking about what people do with Haskell but rather how they do it.

The type system does quite a bit more than just describe cardinality. The single most important feature is typeclasses; you simply can't replicate some of what typeclasses can easily do without a similar type system.

Apart from that, you also want the type system to let you control "effects"--not just state and IO but also things like error management and non-determinism. You also want a good way to reuse the type system to enforce your own domain-specific invariants; this is what GADTs are for.

The only serious effort I know for adding a type system to lisp is typed Racket, and I don't think it does anywhere near as much as Haskell. It certainly does not have typeclasses, and I think it ends up having union types everywhere which are more awkward and bug-prone than the usual sum types languages have. (This is a necessary compromise to integrate well worth normal Racket, but it's still a compromise.)

Beyond that, most people don't use typed Racket at all, so I suppose the main way lisp can come close to Haskell's type system is in having one at all.

As far as homo-iconic syntax goes, I sometimes miss it, but not too often. Having a flexible syntax that can look like math is far more important usually, and Haskell gets most of the way there without being too complicated. I personally think that seething like Agda's mixfix syntax is the best option overall.

[jhuni]

> The type system does quite a bit more than just describe cardinality. The single most important feature is typeclasses; you simply can't replicate some of what typeclasses can easily do without a similar type system.

In the C programming language types are mainly used to describe cardinalities. For example, char is the cardinality of the smallest addressable unit of memory of the machine (often 256). We don't need more then machine cardinalities as entire operating systems have been written in assembly and C. What advantages do type classes and GADTS have that make them worth adopting? Is there any evidence that they make programs more safe and reliable?

> My point with math is that Haskell libraries and code use mathematical abstractions (like various sorts of algebraic structures) far more than lisp; I was not taking about what people do with Haskell but rather how they do it.

I am building a computer algebra system with Lisp in my free time. There are many Lisp computer algebra systems that I have learned a lot from like Maxima, Reduce, and Axiom. One of my favorite computer algebra systems is GAP and it is written in C and not Haskell. I am not convinced that Haskell uses more mathematical abstractions and algebraic structures and I am not familiar with any well maintained computer algebra system written in Haskell.

> Having a flexible syntax that can look like math is far more important usually, and Haskell gets most of the way there without being too complicated.

Math doesn't look like anything. Mathematics is about abstract concepts (especially the natural numbers) not representations. You mean that Haskell is meant to look like math does on paper, but whats so important about using a paper syntax when we have keyboards?

[Locke1689]

Most Lisps are untyped. Typed-Racket and Qi seem to be the standouts. Other than that I would agree that there's not "more mathematical" background.

[maaku]

Type theory and accompanying first-order logic is the foundation upon which mathematics is built. This gives strongly typed languages a much more firm foundation which has the potential t be exploited by theorem-proving programs reasoning about and modifying other programs (e.g, compilers).

I assumed that's what the OP was talking about by saying Haskell was "more mathematical". The situation is analogous to ad-hoc databases vs. those firmly rooted in the relational model.

[jhuni]

> Type theory and accompanying first-order logic is the foundation upon which mathematics is built.

Since when? Mathematics was originally founded on the study of the natural numbers. The mathematics I find most valuable (eunmerative combinatorics) still uses the natural numbers as its foundation and not type theory.

[maaku]

Number theory/abstract algebra, which is the study of natural numbers among other things, is a form of set theory. And set theory is what mathematics calls type theory.

[jhuni]

> Number theory/abstract algebra, which is the study of natural numbers among other things, is a form of set theory.

Let S be the set {a,b} and let T be the set {c,d}. There are two bijections S -> T between these two sets {(a,c),(b,d)} and {(a,d), (b,c)}. These two sets are isomorphic to one another because they have the same cardinality.

The isomorphism classes of sets are cardinalities which are themselves the natural numbers 0,1,2,3,... and infinity. In combinatorics we can just focus on the study of these isomorphism classes rather then sets themselves.

We can enumerate binary relations: ([],[0],[1],[[0 0],[0 0]],[[0 0],[0 1]],[[0 0],[1 0]],[[0 0],[1 1]],[[0 1],[0 0]],[[0 1],[0 1]],[[0 1],[1 0]],[[0 1],[1 1]]). Logical disjunction [[0,1],[1 1]] is equal to 10 in this enumeration.

Using the enumeration of binary relations the entire field of study of graph theory can be described in terms of natural numbers without any need for sets. As a result, graph theory is considered to be a branch of combinatorics. We only need to have sets mathematically when dealing with cardinalities like aleph one that emerge from uncountable sets.

Since analytic number theory deals with the uncountable set of real numbers and abstract algebra deals with operations on sets including the real numbers, these two fields are indeed founded on set theory. Algebraic combinatorics and combinatorial number theory are the branches of these two fields that focus on countable sets.

> And set theory is what mathematics calls type theory.

No it isn't. Just look up differences of type theory from set theory on wikipedia [1]. You almost never hear the word "type" spoken in math courses. According to John Shutt "I took some tolerably advanced math courses in college and graduate school. One thing I never encountered in any of those courses, nor that-I-recall even in the THUG talks, was a type. Sets aplenty, but not types" [2].

[1] Type theory differences from set theory http://en.wikipedia.org/wiki/Type_theory#Difference_from_set...

[2] Where do types come from http://fexpr.blogspot.com/2011/11/where-do-types-come-from.h...

[maaku]

> No it isn't ... You almost never hear the word "type" spoken in math courses.

You misread me. What I said was that "set theory" is the general mathematical framework exactly equal to what we computer scientists call "type theory". We have completely different ontologies for what are essentially the same thing (the differences listed on Wikipedia are superficial/conventional and IMHO of no relevance here or in the article).

Mathematicians deal with sets, countable or otherwise, algebraic manipulations of them, bijective mappings, etc. Computer scientists operate on domains (types), their operators, functions, etc. These are different terminology for the exact same thing.