That's the way Groovy works, too, and I'm a fan of that optional static typing.

~~ Robert.

Mike Austin wrote:
>
>
>
> Not in direct reply, but I thought I'd chime in...
>
> I've been using MiniD for the last few months, which has a few features
> that languages like Python and Ruby don't have. It has (dynamic)
> argument type checking, which catches a lot of dumb typing errors and
> allows for nullable types; true namespaces and modules; and the parser
> is very strict about statements, expressions and general syntax. These
> add up to much better error messages and fewer silly mistakes, while
> still having a completely dynamic runtime. For example:
>
> function foo( bar, baz: array|null )
> {
> this.( bar )( baz ) // .() is MiniD's "perform", or "send"
> }
>
> The choice to use type-checking is yours. If you want to use duck
> typing, don't give it a type. My next choice is Dylan, but it was not
> as dynamic, or should i say reflective, as I needed.
>
> Mike
>
> ------------------------------------------------------------------------
> *From:* John Cowan <cowan@...>
> *To:* langsmiths@yahoogroups.com
> *Sent:* Tuesday, June 23, 2009 2:25:48 PM
> *Subject:* Re: [langsmiths] Re: Duck typing and errors
>
> Brian Hurt scripsit:
>
> > No, the big advantage of static typing is development time. First of
> all,
> > static typing drastically reduces the number of unit tests you need-
> > responsibility for the correctness of many of the constraints that unit
> > tests are checking can instead be ensured automatically by the type
> > system.
>
> That's a big advantage for supporting static typing, but not a big
> advantage for requiring it. Nor is it an advantage particular to static
> typing as opposed to any other sort of compile-time declaration system.
>
> > As an example of what I mean by this, note in the example code
> > I tossed off I casually introduced the FieldName.t type, which
> > (obviously) represents a field name. The underlying representation
> > of this type is probably just a string- but by controlling when and
> > how field names can be created, I can enforce generic constraints.
> > For example, already it's an error if you accidentally reverse the
> > field name and field values.
>
> This is a consideration orthogonal to static vs. dynamic typing: what
> I will call generic vs. specific types. It's perfectly reasonable in a
> dynamically typed language to put the field name into a specific type,
> which provides the same type safety at run time that the statically
> typed version does at compile time. Furthermore, there is nothing about
> a statically typed language that prevents an API designer from using a
> generic type such as String to represent a field name.
>
> It may be true that dynamically- typed-language programmers are more
> likely to use generic types, as a result of the easy availability
> of type-heterogeneous containers such as lists and dictionaries.
> What's more, few languages (CL is the exception here) provide syntax
> for literals of specifically typed objects.
>
> > But you can go further than that. I might not let arbitrary strings be
> > converted into field names, I might only allow the database interface to
> > create field names- and have some function where given a table, you can
> > produce the list of FieldName.t' s that represent that table's fields.
> > This way I gaurentee that a field name is a valid field name of at least
> > some table. With phantom types and some trickery I can even
> gaurentee, in
> > the type system, that the field names are valid for the table being
> > selected against.
>
> This of course is very straightforward in a dynamically typed language
> by writing your own checking routines, if indeed you need them. You have
> a Turing-complete engine, so use it.
>
> > Over the course of say, a thousand bugs, that' s 83 working hours,
> > or over two weeks of time lost.
>
> If you have a thousand bugs of the kind a type system can catch, by all
> means use it.
>
> > You could make a dynamically typed system with variant types and pattern
> > matching, but I've yet to see it.
>
> The Scheme "match" macro does exactly that, and so does Q/Pure, which are
> based on generalized term rewriting.
>
> --
> Dream projects long deferred John Cowan <cowan@...
> <mailto:cowan%40ccil.org>>
> usually bite the wax tadpole. http://www.ccil. org/~cowan
> <http://www.ccil.org/%7Ecowan>
> --James Lileks
>
>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html