[ruby-core:32592] Re: Proposal for Optional Static Typing for Ruby

Hi Matz

Thanks for the reply. I full agree with you (and Alan Kay) that typing =
can be a pain, though due to benefits in more accurate and effective =
tools there are advantages to it. If there was a way to easily and =
reliably get tools as powerful as languages with static typing without =
the need for the typing then I'd be all for it as I love using duck =
typed languages and the freedom they give.

I did consider structural typing and it could be a route to go down. =
Ultimately I'm just wanting a better way for me and others to build =
reliable, powerful tools for Ruby, regardless of how that is approached. =
I did hit a snag when considering structural typing though, which may be =
due to my relative inexperience with structural typing, so you might be =
able to help with a solution.=20

Obviously structural typing is great at easily working out whether two =
objects are technically interchangeable, whether or not they =
conceptually are. However, while you can say that a String object is =
simply one that has methods +, <<, concat, length, split, sub etc, it's =
somewhat harder to say what the argument and return types of those =
methods are (of course that is a somewhat bad example given that the =
return values/types are given for the very base classes and their =
methods, but you get the idea). This is ultimately the main reason for =
me wanting some degree of pre-runtime typing (the return types more than =
the arguments) and I can't see any way to calculate these types without =
type inference, which itself I see snags with.

I'm just wondering if you have any thoughts about getting this method =
type information? I could just be overlooking something that a fresh =
(and far more experienced with Ruby) pair of eyes can see, but I'm just =
struggling a bit with reliable ways to get the type info needed.

Thanks

Martin


On 27 Sep 2010, at 4:29PM, Yukihiro Matsumoto wrote:

> Hi,
>=20
> In message "Re: [ruby-core:32585] Proposal for Optional Static Typing =
for Ruby"
>    on Mon, 27 Sep 2010 20:58:51 +0900, Martin Pilkington =
<[e-mail]> writes:
>=20
> |I know this is my first post on this list and that I'm relatively new =
to the Ruby community, and that this can be a somewhat controversial =
topic (as I've found by asking about it on the #ruby-lang channel).=20
>=20
> Short response:
>=20
>  "I'm not against types, but I don't know of any type systems that
>  aren't a complete pain, so I still like dynamic typing." - Alan Kay
>=20
> Static typing surely has its benefit, but on the other hand, Ruby the
> language strongly encourages duck typing, so that its type system
> should not hinder duck typing.  As a result, the type checking should
> be based on structural types, not nominal types.  I don't think your
> proposal cares about duck typing or considered structural type
> conformance.
>=20
> Although I like your <type> notation, that reminds me the scheme
> object system, iff we don't have to write them often.  I don't think I
> could stand to write <type> everywhere.
>=20
> 							matz.
>=20