On 13 October 2011 13:37, Mike Gran <spk...@yahoo.com> wrote: > >>> Anyway this second, proof side of types, is the side that Scheme does >>> not have. C has a stronger story in that regard. >> >> Lack of types in scheme has made me day-dream about learning >> ocaml or haskell. My pet peeve about scheme is that, when >> maintaining old code, its very very hard to just "know" what type >> some lambda is expecting. And, to me, this makes scheme >> sometimes very hard to read. >> >> very-hard-to-read == bug-prone >> > > It is hard to know what types a procedure expects. I've wondered > why paradigms like the following weren't more popular. > > (define (func a b) > (assert-string a) > (assert-list b) > ... > > In the great never-ending Lisp/Scheme flamewar, I always end up > on the "Lisp/Scheme lacks visual clues" side of the argument. Scheme > is just hard to read.
In the code that I work on, in (func a b), its rarely the case that a and b are merely strings or lists; they're usually some fairly complex structure, where e.g. 'b' is a list where car and cadr must be strings, and caddr may or may not be another list, with certain expectations about car, cadr, etc. I have no clue why it never occurred to me to use the above paradigm, I will definitely start experimenting with it. Any clue on how to indicate that func returns type 'X' ? I don't know if you were trying to make this point but: if one were to code in the above paradigm, and also throw some srfi-9000 syntactic sugar at it, one might be able to get something that resembled ocaml/haskell type declarations. And, for the code that I deal with, this might be the bees knees. --linas
