There are not many examples now :-( Just one simple - computing factorial. You
can find it in the distibution in Kutululu\bin\test folder. The file of interest
is main.module (all .module files are text files).

It may be also interesting to look at definitions of built-in functions in
Kutululu\bin\system folder.

I will try to prepare some intro, so it would be possible to get some idea about
the language in other way than watching source codes.

Rudla


--- In langsmiths@yahoogroups.com, Mike Austin <mike_ekim@...> wrote:
>
> I'm always interested in new languages, but I couldn't find (m)any examples at
the web site or in the distribution.  Where is a brief introduction to the
language?
>
>
>
>
> ________________________________
> From: rudla.kudla <rudla.kudla@...>
> To: langsmiths@yahoogroups.com
> Sent: Tue, November 24, 2009 12:10:45 PM
> Subject: [langsmiths] Kutululu
>
>
> Kutululu is my new programming language with user defined syntax.
> You can find more information at http://www.kutululu.org.
>
> I hope some of the ideas there will be provoking enough to start some
discussion here :-)
>
> Rudla
>

Kutululu is my new programming language with user defined syntax.
You can find more information at http://www.kutululu.org.

I hope some of the ideas there will be provoking enough to start some discussion
here :-)

Rudla

From what I can tell, it sounds like an interesting language, but
neither the wikipedia nor the other documentation linked there, yield
a lot of information about the context and history of the language. Is
there more information available? It'd be useful to at least know the
latest release date and license of the language.

On Mon, Jul 20, 2009 at 5:20 AM, Chuck
Esterbrook<Chuck.Esterbrook@...> wrote:
>
>
> Has anyone on the list checked out this one?
>
> http://en.wikipedia.org/wiki/Claire_(programming_language)
>
> The first class sets sound interesting including the use of making unions of
> classes in lieu of multiple inheritance. Note that their notion of set is
> not just a collection library class like what you might have in .NET or JVM.
> Their sets participate in the language.
>
> But I haven't taken it for a spin yet and I'm just wondering if anyone has?
> Or if not, feel free to comment and discuss on what you see.
>
>

Has anyone on the list checked out this one?

http://en.wikipedia.org/wiki/Claire_(programming_language)

The first class sets sound interesting including the use of making unions of
classes in lieu of multiple inheritance. Note that their notion of set is not
just a collection library class like what you might have in .NET or JVM. Their
sets participate in the language.

But I haven't taken it for a spin yet and I'm just wondering if anyone has? Or
if not, feel free to comment and discuss on what you see.

On 2009-06-23, at 7:05 PM, Robert Fischer wrote:
> That's the way Groovy works, too, and I'm a fan of that optional
> static typing.

Objective-C does this as well.

Personally, I would prefer protocol checking to type checking as any
notion of type as it refers to a implementation (as it does in most
systems) is a violation of encapsulation and over-specifies what is
being done.

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

On 2009-06-23, at 8:25 AM, Brian Hurt wrote:
> Define "validly receive every message".  The only thing you can
> validly do
> for *every* message is just throw an exception.  Otherwise you have to
> either violate the contract and return something unexpected and
> wrong, or
> provide valid implementations for messages such as
> solveHaltingProblem,
> factorProductOfTwoLargePrimes, etc.

Suppose I have a object which can proxy any message across a network.
At compile time, the compiler has no way of knowing what the object on
the other side of the proxy can receive and therefore can infer
nothing about it's "type".

Steve

On Jun 23, 2009, at 7:58 PM, Robert Fischer wrote:

> This is a key culture difference between dynamic and static type
> communities -- static type
> communities want any tiny snippet of code to be obvious without
> context, whereas the dynamic type communities are much more
> comfortable with the idea of code making sense in its surrounding
> context.

The obvious point to make here being that the former is always better
than the latter provided that all other things are equal.

- John

On Jun 23, 2009, at 5:29 PM, Robert Fischer wrote:

> Similarly, with the XML parsing, I might do something like this:
>
> XmlWalker.forText(xmlString).foo.bar.baz.@id[5].item()
>
> Sure, I could translate it into some static-friendly API like:
>
> XmlWalker
> .forText
> (xmlString).child(rootName).child("bar").child("baz").attribute(id,
> 5).item()

How is that more "static-friendly"? Why not just offer a selection
function that takes a list of items to use to descend the tree:

     select : List String -> XMLWalker -> XMLAttribute

You could then do something like this:

     nth 5 . select ["foo", "bar", "baz"] . toXMLWalker

- John

On Jun 23, 2009, at 7:49 PM, Brian Hurt wrote:

> Without looking it up, can you tell me what the operator <+> does?

Without looking it up, can you tell me what the functions 'bind' and
'return' do? How about 'cata' or 'hylo'? Or 'appEndo'? Or 'runKleisli'?

The readability of Haskell has much more to do with its high-level
nature and category theory influences than its choice of operators. If
you're not familiar with the concepts and the names/operators, you
won't understand it. That's no criticism of Haskell.

- John

This is a key culture difference between dynamic and static type communities --
static type
communities want any tiny snippet of code to be obvious without context, whereas
the dynamic type
communities are much more comfortable with the idea of code making sense in its
surrounding context.
   I've probably been spending enough time in the dynamic typing community that
the idea of being
forced to use an API that reads like ".child(...).child(...).child(...)" brings
out a murderous rage
in me.

~~ Robert.

Brian Hurt wrote:
>
>
>
>
>
> On Tue, 23 Jun 2009, Robert Fischer wrote:
>
>  > XmlWalker.forText(xmlString).foo.bar.baz.@id[5].item()
>  >
>  >
>
XmlWalker.forText(xmlString).child(rootName).child("bar").child("baz").attribute\
(id,
> 5).item()
>  >
>  > There's a point to the stunt dynamic types are pulling, and definite
> gains in readability and
>  > maintainability.
>
> I think I actually disagree here. The top one is shorter, granted- but I
> don't think it's more readable. Or rather, I don't think it's more
> readable *in general*.
>
> In this context, you know that you're parsing an XML document because of
> the big "XMLWalker.fortext" at the begining of the line. Without this big
> clue, it's much less obvious that you're walking an XML tree.
>
> Note that I have this same problem with the Haskell communities' less than
> useful addiction to defining operators. Without looking it up, can you
> tell me what the operator <+> does?
>
> Brian
>
>

--
~~ 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

On Tue, 23 Jun 2009, Robert Fischer wrote:

> XmlWalker.forText(xmlString).foo.bar.baz.@id[5].item()
>
>
XmlWalker.forText(xmlString).child(rootName).child("bar").child("baz").attribute\
(id, 5).item()
>
> There's a point to the stunt dynamic types are pulling, and definite gains in
readability and
> maintainability.

I think I actually disagree here.  The top one is shorter, granted- but I
don't think it's more readable.  Or rather, I don't think it's more
readable *in general*.

In this context, you know that you're parsing an XML document because of
the big "XMLWalker.fortext" at the begining of the line.  Without this big
clue, it's much less obvious that you're walking an XML tree.

Note that I have this same problem with the Haskell communities' less than
useful addiction to defining operators.  Without looking it up, can you
tell me what the operator <+> does?

Brian

On Tue, 23 Jun 2009, John Cowan wrote:

> 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.

The advantage to requiring it I've dealt with in another email.

> Nor is it an advantage particular to static
> typing as opposed to any other sort of compile-time declaration system.

Any system of checked metadata about code is a type 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.

What's the advantage of doing this in a dynamically checked language?
Remember- there is where the error actually is, and where the error is
detected.  This is exactly what I was talking about elsewhere- OK, you
have an error.  Somewhere, you're passing "123" in as a field name.
You've probably swapped a field name and value somewhere- but where?
Sure, it probably only takes you five minutes to track down where the
error actually is, but it only takes me thirty second to fire up the
editor, go to the exact location where the error is, and fix it.

>
> 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.

Such type-heterogeneous containers are also available in statically typed
systems.

>> 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.

I do.

Brian

You misunderstand what's going on.

An ActiveRecord class starts out life looking like this:

class Foo < ActiveRecord::Base
end

That's it. It delegates the source of truth to the database at runtime, and the
class is mangled
appropriately.

Similarly, with the XML parsing, I might do something like this:

XmlWalker.forText(xmlString).foo.bar.baz.@id[5].item()

Or:

XmlWalker.forText(xmlString).'**'.foo.bar.baz.@id[5].item()

Or even:

def rootName = parseRootNodeNameFromStandardIn()
XmlWalker.forText(xmlString)."$rootName".bar.baz.@id[5].item()

(I'm very aware that Groovy's XmlSlurper has a different syntax.  But its syntax
very well could
look like the above.)

Forcing me to go through and define an entire graph of types in order to have a
nice syntax for
walking the XML document is simply overkill, and largely wasted.  Particularly
if I only use this
particular path once (and use different paths other times).

Sure, I could translate it into some static-friendly API like:

XmlWalker.forText(xmlString).child(rootName).child("bar").child("baz").attribute\
(id, 5).item()

But the the "child" method calls there are simply noise, providing no more
information but required
to exist so that I can (in effect) side-step the static type system to
communicate the only semantic
piece of information -- its string argument.

There's a point to the stunt dynamic types are pulling, and definite gains in
readability and
maintainability.

~~ Robert.

Brian Hurt wrote:
>
>
>
>
>
> On Tue, 23 Jun 2009, Robert Fischer wrote:
>
>  > This is an obvious case for polymorphism, so an object would provide its
>  > own to_sql implementation. If you didn't want to do that, the Groovy
>  > code could look like:
>  >
>  > def to_sql(Equals e) { "$e.field = $e.value" }
>  > def to_sql(And a) { "(${to_sql(a.a)}) = (${to_sql(a.b)})" }
>  > def to_sql(Or o) { "(${to_sql(o.a)}) or (${to_sql(o.b)})" }
>  > def to_sql(Not n) { "not (${to_sql(n.a)})" }
>  >
>  > You can also this kind of case-based matching via switch statements, if
>  > that's your bag.
>
> So the question then becomes why did ActiveRecord go with monkey patching
> instead of this route?
>
> Note that this exact same solution also works nicely for the XML and JSON
> examples you posted earlier.
>
> Brian
>
>

--
~~ 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

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@...>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
         --James Lileks

On Tue, 23 Jun 2009, Robert Fischer wrote:

> This is an obvious case for polymorphism, so an object would provide its
> own to_sql implementation. If you didn't want to do that, the Groovy
> code could look like:
>
> def to_sql(Equals e) { "$e.field = $e.value" }
> def to_sql(And a) { "(${to_sql(a.a)}) = (${to_sql(a.b)})" }
> def to_sql(Or o) { "(${to_sql(o.a)}) or (${to_sql(o.b)})" }
> def to_sql(Not n) { "not (${to_sql(n.a)})" }
>
> You can also this kind of case-based matching via switch statements, if
> that's your bag.

So the question then becomes why did ActiveRecord go with monkey patching
instead of this route?

Note that this exact same solution also works nicely for the XML and JSON
examples you posted earlier.

Brian

This is an obvious case for polymorphism, so an object would provide its own
to_sql implementation.
  If you didn't want to do that, the Groovy code could look like:

def to_sql(Equals e) { "$e.field = $e.value" }
def to_sql(And a) { "(${to_sql(a.a)}) = (${to_sql(a.b)})" }
def to_sql(Or o) { "(${to_sql(o.a)}) or (${to_sql(o.b)})" }
def to_sql(Not n) { "not (${to_sql(n.a)})" }

You can also this kind of case-based matching via switch statements, if that's
your bag.

~~ Robert.

Brian Hurt wrote:
> let rec to_sql = function
> | Equals(field, value)
> -> (FieldName.to_string field) ^ " = " ^ value
> | And(a, b) ->
> "(" ^ (to_sql a) ^ ") and (" ^ (to_sql b) ^ ")"
> | Or(a, b) ->
> "(" ^ (to_sql a) ^ ") or (" ^ (to_sql b) ^ ")"
> | Not(a) ->
> "not (" ^ (to_sql a) ^ ")"
> ;;

~~ 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

On Tue, 23 Jun 2009, John Cowan wrote:

> Brian Hurt scripsit:
>
>> I think I'm going to argue that.  Dynamic typing's main strengths
>> are 1.  Algol-68 type systems are exceeding limited and broken
>> (and this was known in 1968), and 2. you don't need to know much to
>> implement a dynamic system.  To implement a proper (not-broken, ocaml-
>> or haskell-like) static type system you need to know type theory-
>> which means reading books and published papers.
>
> Static typing is inherently more restrictive than dynamic typing.

By definition, yes.

> That is, there are well-typed programs that any decidable static type
> system will reject.  (If your type system is Turing-complete, you don't
> have this problem -- but you have other and worse problems.)  The main
> advantage of static typing is that it permits compile-time checks to
> replace run-time ones, thus improving performance

Not just performance.  Actually, the performance advantage is minor at
best- and can be offset by other things.  For example, it's not unusual to
see dynamically typed lisps beat lazily evaluated Haskell in performance-
the laziness performance penalty of Haskell can be as big a hit as the
dynamic typing penalty of Lisp.  And neither language is that much slower
than the eagerly evaluated statically typed languages like SML or Haskell.

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.  Not all, but many- and since unit tests often comprise about 80%
of the code, reductions in this area equate to huge reductions in the
needed code base.  Reduce the number of unit tests you need by half, and
you've reduced the overall code base size by 80%.

Exactly how many unit tests can be superseceded by static typing is a
function of what problem domain you're dealing with and your utilization
of the possibilities of the type 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.

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.

The other huge win for static typing is debugging.  Generally, a type
error comes with the file name, the line number, and some clue as to what
the problem is- and my experience has been that 95%+ of the time it's spot
on- that is where the bug is.  This doesn't seem to be that big of a win-
it's the difference between spending 5 minutes with a debugger to track
down the location of an error vr.s just going directly there, but these
five minutes add up.  Over the course of say, a thousand bugs, that' s 83
working hours, or over two weeks of time lost.

So this is my point: yes, there is a cost to static typing.  Some
correctly typed programs are accepted, and some solutions are harder to
implement (for example, write a object that wraps another object and logs
all the methods calls to that object).  But there's also an advantage to
static typing.  The question is whether the benefit out weighs the cost,
and my experience is that it does.  Hugely.

> -- but a gradual
> typing system combined with a profiler would be just as effective.
> The problem with CL-style gradual typing is that most implementations
> don't give you any guidance about when to use it -- and sometimes type
> information is actually pessimizing for a given implementation.
>
>> Say what you want to do is to be able to encode complex where-clause logic
>> into a SQL query.  My preferred solution there would be to simple
>> represent the where-clause logic as a variant type:
>>
>> type t =
>>   | Equals of FieldName.t * string
>>   | And of t * t
>>   | Or of t * t
>>   | Not of t
>> ;;
>
> I agree with this general design; string APIs are an abomination.
> However, it works equally well in a dynamically typed system.

You could make a dynamically typed system with variant types and pattern
matching, but I've yet to see it.

Note that pattern matching is the flip side of variant types, and it's
what makes variant types rock.  For example, I can convert the above type
into it's equivelent SQL like:

let rec to_sql = function
 	 | Equals(field, value)
 		 -> (FieldName.to_string field) ^ " = " ^ value
 	 | And(a, b) ->
 		 "(" ^ (to_sql a) ^ ") and (" ^ (to_sql b) ^ ")"
 	 | Or(a, b) ->
 		 "(" ^ (to_sql a) ^ ") or (" ^ (to_sql b) ^ ")"
 	 | Not(a) ->
 		 "not (" ^ (to_sql a) ^ ")"
;;

It'd be interesting to see the ruby/groovy/python equivelent to this code.

Brian

Brian Hurt scripsit:

> I think I'm going to argue that.  Dynamic typing's main strengths
> are 1.  Algol-68 type systems are exceeding limited and broken
> (and this was known in 1968), and 2. you don't need to know much to
> implement a dynamic system.  To implement a proper (not-broken, ocaml-
> or haskell-like) static type system you need to know type theory-
> which means reading books and published papers.

Static typing is inherently more restrictive than dynamic typing.
That is, there are well-typed programs that any decidable static type
system will reject.  (If your type system is Turing-complete, you don't
have this problem -- but you have other and worse problems.)  The main
advantage of static typing is that it permits compile-time checks to
replace run-time ones, thus improving performance -- but a gradual
typing system combined with a profiler would be just as effective.
The problem with CL-style gradual typing is that most implementations
don't give you any guidance about when to use it -- and sometimes type
information is actually pessimizing for a given implementation.

> Say what you want to do is to be able to encode complex where-clause logic
> into a SQL query.  My preferred solution there would be to simple
> represent the where-clause logic as a variant type:
>
> type t =
>   | Equals of FieldName.t * string
>   | And of t * t
>   | Or of t * t
>   | Not of t
> ;;

I agree with this general design; string APIs are an abomination.
However, it works equally well in a dynamically typed system.

--
Yes, chili in the eye is bad, but so is your    John Cowan
ear.  However, I would suggest you wash your    cowan@...
hands thoroughly before going to the toilet.    http://www.ccil.org/~cowan
         --gadicath

On Tue, 23 Jun 2009, Robert Fischer wrote:

> This is certainly true -- dynamic typing's strengths are more than just
> duck typing.

I think I'm going to argue that.  Dynamic typing's main strengths are 1.
Algol-68 type systems are exceeding limited and broken (and this was known
in 1968), and 2. you don't need to know much to implement a dynamic
system.  To implement a proper (not-broken, ocaml- or haskell-like) static
type system you need to know type theory- which means reading books and
published papers.

> Programatically extending types at runtime (a la Rails's
> ActiveRecord) and handling arbitrary messages (a la Groovy's XmlSlurper)
> are very powerful capabilities.  Now, there are down sides, too --
> turning types into a global, stateful variable is bad in all the ways
> that we, as programmers, know global variables are bad.

Extending types at run time are not the only, or even the best I'd argue,
way to skin that cat.

Say what you want to do is to be able to encode complex where-clause logic
into a SQL query.  My preferred solution there would be to simple
represent the where-clause logic as a variant type:

type t =
 	 | Equals of FieldName.t * string
 	 | And of t * t
 	 | Or of t * t
 	 | Not of t
;;

You can elaborate this type with all the extra operations you want.  Now
you only need one function:

 	 perform_query : t -> QueryResult.t

to get you all the abilities of ActiveRecord style monkey patching.  I can
even envision an optimize function:
 	 optimize : t -> string list -> QueryResult.t
If you're going to be performing a query with the same structure but
different values multiple times.

One of the problems a lot of programmers have- and this is one of the
reasons learning multiple languages is important- is that they confuse the
solution of the problem with the problem itself.  This is also known as
the Golden Hammer syndrome.

Brian

Examples of things I can do if I accept any message: navigate an XML document,
build a JSON object.

http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper
http://groovy.codehaus.org/Builders

~~ Robert.

Brian Hurt wrote:
>
>
>
>
>
> On Tue, 23 Jun 2009, Steve Dekorte wrote:
>
>>
>> On 22 Jun 2009, at 07:26 pm, Brian Hurt wrote:
>>> anyone who replies "but static typing can't do duck typing!"
>>> will be told to go learn Ocaml
>>
>>
>> If type inference is done on the basis of messages that an object can
>> receive, what happens when via message forwarding* every object can
>> validly receive every message?
>
> Define "validly receive every message". The only thing you can validly do
> for *every* message is just throw an exception. Otherwise you have to
> either violate the contract and return something unexpected and wrong, or
> provide valid implementations for messages such as solveHaltingProblem,
> factorProductOfTwoLargePrimes, etc.
>
> Also, this is not duck typing. This is dynamic dispatch.
>
> Brian
>
>

--
~~ 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

On Tue, 23 Jun 2009, Steve Dekorte wrote:

>
> On 22 Jun 2009, at 07:26 pm, Brian Hurt wrote:
>> anyone who replies "but static typing can't do duck typing!"
>> will be told to go learn Ocaml
>
>
> If type inference is done on the basis of messages that an object can
> receive, what happens when via message forwarding* every object can
> validly receive every message?

Define "validly receive every message".  The only thing you can validly do
for *every* message is just throw an exception.  Otherwise you have to
either violate the contract and return something unexpected and wrong, or
provide valid implementations for messages such as solveHaltingProblem,
factorProductOfTwoLargePrimes, etc.

Also, this is not duck typing.  This is dynamic dispatch.

Brian

This is certainly true -- dynamic typing's strengths are more than just duck
typing.
Programatically extending types at runtime (a la Rails's ActiveRecord) and
handling arbitrary
messages (a la Groovy's XmlSlurper) are very powerful capabilities.  Now, there
are down sides, too
-- turning types into a global, stateful variable is bad in all the ways that
we, as programmers,
know global variables are bad.

~~ Robert.

Steve Dekorte wrote:
>
>
>
>
> On 22 Jun 2009, at 07:26 pm, Brian Hurt wrote:
>> anyone who replies "but static typing can't do duck typing!"
>> will be told to go learn Ocaml
>
> If type inference is done on the basis of messages that an object can
> receive, what happens when via message forwarding* every object can
> validly receive every message?
>
> * Smalltalk's DoesNotUnderstand: or Objective-C's forward:, or Lua's
> index metamethod, etc - Io, Python, Ruby, Self and other languages
> support this as well.
>
>

--
~~ 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

On 22 Jun 2009, at 07:26 pm, Brian Hurt wrote:
> anyone who replies "but static typing can't do duck typing!"
> will be told to go learn Ocaml


If type inference is done on the basis of messages that an object can
receive, what happens when via message forwarding* every object can
validly receive every message?

* Smalltalk's DoesNotUnderstand: or Objective-C's forward:, or Lua's
index metamethod, etc - Io, Python, Ruby, Self and other languages
support this as well.

On Mon, 22 Jun 2009, David Benn wrote:

> The mantra for dynamically/duck-typed languages often is "test test test".
> Tesing obviously matters, but my view these days as a practitioner, is that
> testing should not be required to find certain classes of errors. pylint -e
> and pychecker will find all kinds of problems, only some of which are
> outright errors, but are highly configurable.

I'll take this a step further and assert that:

1) If they're problems, they should be fixed even if they're not
technically "bugs"- things are that portability or maintainance problems
or even just code smells aren't technically bugs today, but they will be
tomorrow, and this way at least they'll stop hiding the real bugs, and

2) tests of the sort pylint and pychecker perform should not be optional.
The problem with optional checks is that the programmers who most need
them are the ones most inclined to not run them, or simply ignore their
output.

At which point I go "welcome to static typing".

By the way, anyone who replies "but static typing can't do duck typing!"
will be told to go learn Ocaml (yes, it can- it just requires a type
theory more advanced than Algol 68's, and thus is unknown to mainstream
developers).

Brian

On Sun, 21 Jun 2009, eike.welk wrote:

> --- In langsmiths@yahoogroups.com, Mike Austin <mike_ekim@...> wrote:
>> Are the stack traces descriptive enough that you can go back up a few
>> methods easily to find the type error?
> I use Python which is also a duck typing language.
>
> In my experience the missing type check at the beginning of a
> function/method poses no big problems. You usually don't get very
> far with the wrong object. Therefore the line where the error
> happened is very often enough to understand the error.
>
> The absence of type checking is however problematic in rarely used
> code; for example error message formatting. You may then never trip
> this error with your testing code.

The other realm where lack of type chcking becomes problematic is
where an instance variable gets populated with a object of the wrong
type in the constructor.

Then the type violation occurs on a method invocation, and the bug is
nowhere on the stack trace.

In ruby I cope with that by extending the Object class to have static and
polymoprhic type check methods and a "quacks_like" method.

I then invoke these methods as precondition checks on the arguments of
the constructor.

eg

class SomeObj
    def initialize( a_number, a_foo, a_duck)
      @number = a_number.polymorphic_type_check Numeric
      @foo = a_foo.static_type_check Foo
      @duck = a_duck.quacks_like :qwaark
    end

    def sound_alarm
      @duck.qwaark
    end
end

# With type checks, the code crashes here, where the bug is..
o = SomeObj.new( 1, Foo.new, Possum.new)

# Without type checks the code crashs on the next line (where the bug isn't)
o.sound_alarm


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

--- In langsmiths@yahoogroups.com, Mike Austin <mike_ekim@...> wrote:
> Are the stack traces descriptive enough that you can go back up a few
> methods easily to find the type error?
I use Python which is also a duck typing language.

In my experience the missing type check at the beginning of a
function/method poses no big problems. You usually don't get very
far with the wrong object. Therefore the line where the error
happened is very often enough to understand the error.

The absence of type checking is however problematic in rarely used
code; for example error message formatting. You may then never trip
this error with your testing code.

>Would it be just as easy to trace
> errors in a non-interactive stack trace, or is it the environment that
> makes the difference?
I think that graphical development environments and debuggers
generally make programmers more productive. And if you really have
an error deep in some library code, it certainly helps to have a
clickable stack trace, which opens the files automatically.

For my own language I try to format the error messages like Python's
error messages. For some time it really convinced the PyDev
development environment to go to the correct line of code, when my
compiler created an error message. (It's broken now.)

Kind regards,
Eike.