guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A bit further toward the flamewar


From: Linas Vepstas
Subject: Re: A bit further toward the flamewar
Date: Thu, 13 Oct 2011 16:42:45 -0500

On 13 October 2011 13:37, Mike Gran <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]