Re: A bit further toward the flamewar

[Linas Vepstas <linasvepstas@gmail.com>]

On 13 October 2011 20:07, Ian Price <ianprice90@googlemail.com> wrote:
> Linas Vepstas <linasvepstas@gmail.com> writes:
>
>> 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.
>
> Just because scheme doesn't have type declarations doesn't mean you
> can't add them. I often write code that looks like
>
> ; partition : (A -> Boolean) Listof(A) -> Listof(A) Listof(A)
> (define (partition pred list) ...)
>
> and I also make heavy use of 'assert', and less frequently, a macro of
> mine called 'assert-lambda' which looks like
>
> (lambda ((a procedure?) (b list?)) ...)
>
> I don't, in general, check return types, but I do try and make sure that
> they obey the declaration comment. Having a built-in type/contract
> syntax, like Racket has, would be nice as I could move these comments
> into code, but this is better than nothing.

Well, I see two choices:
1) Let the conversation slide, and incorporate above thoughts as 'best
practices' into my code.
2) Flame-war.

In the spirit of 2),

Andy Wingo wrote:
> I can't find the source right now, but I think it was Matthias Felleisen
> who gave a variant of Greenspun's tenth law, that "any sufficiently
> complex Lisp program has a buggy, incomplete ML program in the
> comments".

So the proposal is: (shout me down, when ready): create a new srfi,
defining an ML-like conception of types, so that scheme functions can
be annotated with types. The goal here is not so much to do
type-checking at run-time, but to allow static type checking.   That
is, one could create a "type checker tool", which one could invoke
ad-hoc, during development, to make sure that my scheme programs are
consistent with their handling of types. This is static type checking
--  as, for the most part, I am not interested in type-checking during
runtime, for two reasons: performance, and also because I want to
avoid the hard-to-debug problem where I only pass the wrong type only
once in a million.

Basically, as a debugging/development tool, everything I've read about
ML (e.g. the Jane's street commentary) is that the static
type-checking in ML is a powerful means of avoiding developer errors.
It'd be neat if I could get this feature in scheme.

BTW, as a token nod to C: please be aware that the Linux Kernel folks
have been busy creating and extending a static type-checking system
for C, which is used extensively in the linux kernel sources. The goal
there is to avoid accidentally passing user-space pointers into the
kernel (where they are invalid), and to avoid calls to __init routines
during runtime (because they no longer exist after initialization).
Note that this kind of type-checking is not possible in "ordinary" C.
I can't comment on how "well-designed" the system is, but it has been
very effective in finding zillions of bugs in the linux kernel.

--linas