Charles Oliver-Nutter: "The dream, as I see it, would be to use a Ruby-like syntax to wire up any arbitrary types using what looks generally like idiomatic Ruby code. For example, our friend fib(). The same fib() method I showed before, executing against primitive integer values, could execute against boxed Integer objects or BigInteger objects just by specifying the right plugin. So if within the context of a file, I declare that "fixnum" types are to be represented as BigInteger objects, and math operations against them are to call appropriate methods on BigInteger, so be it...that's what comes out the other side."
Now this is interesting - an algorithm that can be generalised by using pluggable type resolution. It reminds me of something Alex Stepanov said in the "Money Oriented Programming" interview: "Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically." In that interview Stepanov defined generic programming as "finding the most abstract representations of efficient algorithms."
This type wiring does makes wonder (again) what would happen if Python had optional type declarations for function arguments. Aside from being able to look at a function and know what it accepts, it could give a type checker (and ultimately a JIT) a lot of information. Cobra allows you to say that an argument acts "as" a type. Scala makes you declare types in functions. It's an interesting tradeoff.
10 Comments
Those JRuby guys continue to seriously impress me.
> This type wiring does makes wonder (again) what would happen if Python had optional type declarations for function arguments.
I have to find an optionally typed language to play with at some point. To be honest, it freaked me out a bit when Guido put out that type annotation paper a few years ago. It feels so icky to me. I can't explain why - I figure it has to be that I'm just extremely ignorant of benefits like the ones you've described here.
Ryan,
"Those JRuby guys continue to seriously impress me."
Isn't it!?
"It feels so icky to me."
Me too. And then you work with person after person coming to Python who wants to know what a method "takes". And you're like, um...
Scala was the language that persuaded me method declarations aren't the end of the world (where they're not optional). My fuzzy knowledge of interpreters/compilers suggests that you get a good bang for the buck with them. Cobra is worth a look as it has Python syntax and would indicate what they'd look like - the "as" thing doesn't seem so bad, even if it's a bit VBish.
You may be aware of this, but Haskell has a feature which is very much like this. The function "fib" has the type "(Num t) => t -> t" which means it takes some type which has a "Num" instance to something of the same type.
This lets third party coders write their own "Num" instance (e.g. for Fixnums, in your example) which is then used by the code of "fib". This is more powerful than normal object orientated dispatch because e.g. numerical literals in "fib" will be constructed to the type supplied by the third party code too!
But then, you certainly aren't going to be writing idiomatic Ruby code in Haskell :-)
Better tools. No reason a type inferencer could not be written for Python or Ruby as-is. Most of the time the type would be trivial, or in this case instead of "type" it would determine which of the known classes using the available code could be applied. And so in some cases the "type" would b a union of known applicable classes.
I don't think "optional typing" is going to provide the significant leap in understanding people are hoping for. Better to use a language with "mandatory types" and a good type inferencer. Actually, better to use a dynamic language and good tests and tools. But if you really want types and the restrictions they maintain, then stay away from dynamic languages. It seems that simple.
Why not just do implied static typing and structural typing? Then you get the succinctness and the interoperability for free. You wouldn't specify it within the context of a file, but in the context of the arguments.
What I said is what Max was saying above. I don't know how I missed that comment the first time.
Patrick,
I said "optional type declarations for function arguments." Your quote, "optional typing", is a straw man. I'm pretty sure you know where I stand wrt languages, but I don't see the harm in wondering whether or how declarations can be mixed.
I'm playing with something on a similar line in an interpreter I'm playing with, but restricting arithmetic operators to fields so you only need to check the type on the first trace, ie typeof(A op B) = min(typeof(A), typeof(B)) when T1 < T2 iff there exists a coercion from T2 to T1. For most non-numeric types, the cost of the operation swamps the cost of the dispatch mechanism. If you keep algorithms generic, you can switch to different representations (bignum, complex, interval, vector) without having to rewrite the code. So I'd vote for minimal annotation and inference, but inference guided trace optimisation.
Not to ruin the party, but wasn't that C++ Templates that statically checked for the compatibility of operations in generic code? So when you had a template based quicksort algorithm, you'd have to supply a template parameter that supports some compare operation?
I think the problem with type systems is that there is a very fine line between what you get and what you have to pay. I think there is certainly value in type systems, like knowing what a method takes, or forcing programmers to give certain behaviours a name which you can talk about (interfaces).
But I also think that type systems tend to be a real pain, especially when they get more complex than Java (which is arguably not very expressive). The more expressive a type system is, the harder it gets to understand it. And at some point you see the language designers themselves discuss on their mailing list whether a certain expression is indeed valid, and if it is, what it might mean ... we should really thrive for code that is easier to understand, and a complex type system a la Haskell / Scala / ... doesn't really help IMHO.
n7l8uG <a href="http://spdenctefsls.com/">spdenctefsls</a>, [url=http://taqzvftwyhxm.com/]taqzvftwyhxm[/url], [link=http://ymesudhyyian.com/]ymesudhyyian[/link], http://atnupfzcfiue.com/