On 2005.12.11 09:21, Jakub H. [email protected] wrote:
"It is designed to be used not as a development tool but rather as a
means to generate efficient
executable images either for application delivery or for production
research runs. "
It’s worth in the final case, not in the general one. 
Eivind E. had some good ideas regarding type inference loosely
based on the implementations of the self language. Essentially, most
of the goodness of static typing for the compiler/interpreter and none
of the terrible and useless burden of static typing for the programmer.
You may have some luck scouring the archives for his messages.
Jakub
E
[email protected] ha scritto:
require “behavior/strongtyping”
def foo(String x, y)
end
In this example, x must be a String, while y can be anything. In
effect, optional typing.
s/typing/ancestry-checking/
I probably said it many times, but what if we provided real type
checking?
I think this is what common lisp does. Checking against an ancestor is
just a subset of a general checking-against-some-real-procedure.
We could default to calling === to get ancestor checking for free.
Oh, the nicety of
def Math.sqrt(Positive p)
gabriele renzi wrote:
I probably said it many times, but what if we provided real type checking?
What does the words “real”, “type”, and “checking” means?
James
–
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
On 11/12/05, gabriele renzi [email protected] wrote:
Oh, the nicety of
def Math.sqrt(Positive p)
Hm. No. That would end up requiring a significant change to Ruby,
because sqrt is legal on negative numbers, as long as you have
imaginary (complex) number support available. So you would then have
to have overloading instead of simple overriding as Ruby currently
does, because you’d need def Math.sqrt(Positive p) and def
Math.sqrt(Negative p).
Overloading, I have come to believe, is a nightmare compared to
duck-typing. That’s one of the reasons I oppose anything that
threatens to put it into Ruby, because it’s a mess.
-austin
James B. ha scritto:
gabriele renzi wrote:
I probably said it many times, but what if we provided real type
checking?
What does the words “real”, “type”, and “checking” means?
being not a native english speaker I won’t try to explain each single
word, I beg your pardon
But trying to answer the core question (or what I think it is), I mean
that using the full power of the language to write a guard function for
an argument you could assert every possible constraint whatever it’s
needed for it, based on ancestry, state of the object, public interface
or whatever.
This basically encompasses everything that can be expressed in ruby, so
I think it matches the idea of a type withouth needing to understand
what a type is.
Austin Z. ha scritto:
On 11/12/05, gabriele renzi [email protected] wrote:
Oh, the nicety of
def Math.sqrt(Positive p)
Hm. No. That would end up requiring a significant change to Ruby,
because sqrt is legal on negative numbers, as long as you have
imaginary (complex) number support available.
yeah, I’m not really suggesting changing Math.sqrt, just an example.
So you would then have
to have overloading instead of simple overriding as Ruby currently
does, because you’d need def Math.sqrt(Positive p) and def
Math.sqrt(Negative p).
Overloading, I have come to believe, is a nightmare compared to
duck-typing. That’s one of the reasons I oppose anything that
threatens to put it into Ruby, because it’s a mess.
I was thinking of multimethods, more than simple overloading C++ style,
but I’m not sure if that belongs to ruby so I won’t argue on this.
But would you please explain why do you think multiple dispatch is a bad
thing, it would be interesting to hear the reasons that brought you to
this conclusion.
On 12/5/05, robertj [email protected] wrote:
i thought i have seen something like that for ruby sometime and
somewhere but i can not find it anymore (or maybe i had simply
visions)
I’ve got an implementation that works more or less like that available
at Index of /~eivind/ruby/types/
It also allows more complicated declarations (respond_to checks,
conditional series of parameters, handling of repeats, etc, etc).
If you find ways to use this that turn out to actually be an advantage
in practice, I’d appreciate a mail describing your use. When I tried
to use it with the way I program, I found that it didn’t catch errors
any earlier than I’d get them from MethodMissing anyway, and that it
got in the way of my refactoring. That doesn’t mean it couldn’t be
useful for somebody else, of course.
Eivind.
On 11/12/05, gabriele renzi [email protected] wrote:
Austin Z. ha scritto:
On 11/12/05, gabriele renzi [email protected] wrote:
Oh, the nicety of
def Math.sqrt(Positive p)
Hm. No. That would end up requiring a significant change to Ruby,
because sqrt is legal on negative numbers, as long as you have
imaginary (complex) number support available.
yeah, I’m not really suggesting changing Math.sqrt, just an example.
Yeah, but it’s a perfect example of what’s wrong with trying to put
class restrictions as signatures in Ruby methods.
So you would then have to have overloading instead of simple
overriding as Ruby currently does, because you’d need def
Math.sqrt(Positive p) and def Math.sqrt(Negative p).
Overloading, I have come to believe, is a nightmare compared to
duck-typing. That’s one of the reasons I oppose anything that
threatens to put it into Ruby, because it’s a mess.
I was thinking of multimethods, more than simple overloading C++
style, but I’m not sure if that belongs to ruby so I won’t argue on
this.
But would you please explain why do you think multiple dispatch is a
bad thing, it would be interesting to hear the reasons that brought
you to this conclusion.
Part of it is the mess that is C/C++; part of it is the mess that is
Java. If I were able to say something like:
class Foo acts as java.util.String
{
// …
}
class Bar
{
public String baz(String x) { … };
}
it might be okay. I’m not necessarily after an inheritance relationship,
but even that’s difficult. I am really finding that I prefer writing
code that I want to say “I need this behaviour” not “I need this class.”
It’s much harder to express that in a multimethod sort of thing, which
is predicated primarily on a preconceived notion that the only way to
get polymorphism is to specify multiple methods that deal with classes.
-austin
Austin Z. ha scritto:
yeah, I’m not really suggesting changing Math.sqrt, just an example.
Yeah, but it’s a perfect example of what’s wrong with trying to put
class restrictions as signatures in Ruby methods.
I fail to see how redefining a method is better than defining a
specialized version for your own purposes leaving all the rest working
with other implementations, but I am quite dumb usually, so it is ok.
public String baz(String x) { … };
}
it might be okay.
I’m not necessarily after an inheritance relationship,
but even that’s difficult.
I think you could easily do this with a multimethod dispatch defaulting
on #=== in ruby, asserting a pseudo is-a property like
def String.===( Foo f) true end
But now I understand your reasons, thanks for sharing.