From: jstern@... (Josh Stern)
Date: 2000-12-14T01:40:02+09:00
Subject: [ruby-talk:7158] Re: Ruby in the US

hipster  <hipster@xs4all.nl> wrote:
>On Thu, 14 Dec 2000  00:10:02 +0900, Josh Stern wrote:
>[snip]
>> I personally believe that some form of strong typing is invaluable
>> for large projects, but it makes quick development much slower,
>> so Ruby is potentially a great compliment to strongly typed
>> languages just for that reason.  But it would also be nice
>> to have flexible facilities for typing and 'design by contract'
>> that operate at run time in Ruby when in 'debug mode', and
>> have little or no overhead when in normal mode - some
>> run time device that is, say, comparable to the assert() macro
>> in C.  I just started thinking about Ruby two weeks ago, and just
>> got your excellent book last weekend, so I'm not qualified to
>> say what the best way is to implement that in Ruby (perhaps
>> a mixin for adding extra type info and argument signatures
>> to functions??).

>I've written a proof-of-principle extension to class Module to do just
>that. It enables you to use typed attributes and typed functions
>(i.e., typed parameters and a typed return value).
>
>The declaration syntax is obfuscated and needs some more thought:
>
>class SomeClass
>  # attribute declaration: tattr [:name, Type], ...
>
>  # C analogue: String foo; SomeClass bar;
>  tattr [:foo, String], [:bar, SomeClass]
>
>  # function declaration: tdef [:name, ReturnType, [[:param, Type], ...]]
>
>  # C analogue: String f1(void)
>  tdef [:f1, String] do
>    body
>  end
>
>  # C analogue: void f2(String a, Array b)
>  tdef [:f2, nil, [[:a, String], [:b, Array]]] do
>    body
>  end
>end
>
>It throws descriptive TypeMismatch exceptions:
>
>attribute mismatch:
>  Type mismatch: attr Foo::name: expected String, got Fixnum
>parameter and retval mismatch:
>  Type mismatch: func Foo::f3 param txt: expected String, got Bar
>  Type mismatch: func Foo::f4 retval: expected String, got NilClass
>
>I'm fleshing out some details (syntax, maybe pre/postcondition
>lambdas) and will announce it When It's Ready[tm]  ;)

It sounds like a good start - the tricky part, as I see it,
is to deal with conditions that have dynamic run time scope.
For instance, it would be nice to have the ability to check
some analog of 'const correctness' - i.e. so it can
be checked that a function keeps a promise not to modify
its arguments.  We don't want that to mean the converse - that the 
function can only accept those arguments that cannot be modified.
So it seems like the function would need to attach an attribute
to the arguments on entry saying "can't modify in this runtime 
scope", and remove it on exit (without destroying attributes
posted by other functions).  That suggests the const attribute
should be some sort of a bit vector with positions 
corresponding to depth in the call stack.

-= Josh