How come most Lisps and Schemes are dynamically typed? Does static typing not mix with some of their common features?
+9
A:
Typing and s-expressions can be made to work together, see typed scheme.
Partly it is a historical coincidence that s-expression languages are dynamically typed. These languages tend to rely more heavily on macros, and the ease of parsing and pattern-matching on s-expressions makes macro processing much easier. Most research on sophisticated macros happens in s-expression languages.
Typed Hygienic Macros are hard.
Doug Currie
2010-06-01 20:50:43
Typed scheme is not statically typed, it provides types as error checking. Static typing is refusing to compile unless the compiler can prove the program is entirely typed safe. Typed scheme still produces runtime type errors, in static typing this isn't possible.
Lajla
2010-06-09 05:19:07
@Lajla, yes, though I didn't say that typed scheme was statically typed.
Doug Currie
2010-06-09 12:12:16
+7
A:
When Lisp was invented in the years from 1958 to 1960 it introduced a lot of features both as a language and an implementation (garbage collection, a self-hosting compiler, ...). Some features were inherited (with some improvements) from other languages (list processing, ...). The language implemented computation with functions. The s-expressions were more an implementation detail ( at that time ), than a language feature. A type system was not part of the language. Using the language in an interactive way was also an early implementation feature.
The useful type systems for functional languages were not yet invented at that time. Still until today it is also relatively difficult to use statically typed languages in an interactive way. There are many implementations of statically typed languages which also provide some interactive interface - but mostly they don't offer the same level of support of interactive use as a typical Lisp system. Programming in an interactive Lisp system means that many things can be changed on the fly and it could be problematic if type changes had to be propagated through whole programs and data in such an interactive Lisp system. note that Some Schemers have a different view about these things. R6RS is mostly a batch language generally not that much in the spirit of Lisp...
The functional languages that got invented later with static type systems then also got a non-s-expression syntax - they did not offer support for macros or related features. later some of these languages/implementations used a preprocessor for syntactic extensions.
Rainer Joswig
2010-06-01 23:26:19
There is no semantics described in R6RS for interactive use of the language. for example EVAL is a library function and completely underspecified. Implementations may try to work around that, but it seems also that the authors of R6RS were not interested in interactive use. So there is nothing that talks about libraries and REPLs for example. Generally I'm completely underwhelmed by the quality of the R6RS standard, besides the technical limitations of the language described. I would hope that R7RS gets better.
Rainer Joswig
2010-06-04 08:41:21
A:
Static typing is lexical, it means that all information about types can be inferred from reading source code without evaluating any expressions or computing any things, conditionals being most important here. A statically typed language is designed so that this can happen, a better term would be 'lexically typed', as in, a compiler can prove from reading the source alone that no type errors will occur.
In the case of lisp, this is awkwardly different because lisp's source code itself is not static, lisp is homo-iconic, it uses data as code and can to some extend dynamically edit its own running source.
Lisp was the first dynamically typed language, and probably for this reason, program code itself is no longer lexical in Lisp.
Edit: a far more powerful reason, in the case of static typing you'd have to type lists. You can either have extremely complex types for each lists which account for all elements, of demand that each element has the same type and type it as a list of that. The former option will produce hell with lists of lists. The latter option demands that source code only contains the same type for each datum, this means that you can't even build expressions as a list is anyhow a different type than an integer.
So I dare say that it is completely and utterly infeasible to realize.
Lajla
2010-06-09 02:46:19
It is merely hard, not impossible. See MetaML and MetaOCaml for counter-examples. And dependently-typed languages can do this too - see the experiments with partial evaluation in Idris.
Jacques Carette
2010-06-18 20:24:34
One has to remove so much that one can hardly speak of 'S-expression based' any more. A central idea to S-expressions is the apply function, which makes code itself dynamic, surely it is then impossibly to statically prove the absence of type errors.Looking at MetaML and MetaOCaml, I don't see any indication that they are S-expression based or homo-iconic.
Lajla
2010-06-19 08:01:16