dblack@wobblini.net ha scritto:
Hi --
Evan Webb mentioned that it would be possible to add a pseudo type
system via Behaviors. He may even have a working implementation for
Sydney, but I'll have to double check. It would look something like
this:
# pseudocode
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)
···
On Sun, 11 Dec 2005, Daniel Berger wrote:
Christian Neukirchen wrote:
Oh, but the time it actually needs to compile and the megabytes of C
it generates... not worth in the general case, IMO.
And Stalin code still is far not as run-time dynamic as Ruby. (Which
is the real problem. We should have something like "eval-on-compile".)
Well, that's the "static language implementation" part. 
You cold treat it as a compiler of a dynamic language into a fast static form, which is something the docs say anyway:
"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. 
Jakub
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
···
On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
Oh, the nicety of
def Math.sqrt(Positive p)
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
Christian Neukirchen wrote:
> Oh, but the time it actually needs to compile and the megabytes of C
> it generates... not worth in the general case, IMO.
>
> And Stalin code still is far not as run-time dynamic as Ruby. (Which
> is the real problem. We should have something like "eval-on-compile".)
>
Well, that's the "static language implementation" part. You cold
treat it as a compiler of a dynamic language into a fast static form,
which is something the docs say anyway:
"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 Eklund 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
···
On 2005.12.11 09:21, Jakub Hegenbart <kyosuke@seznam.cz> wrote:
James Britt 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 Ziegler ha scritto:
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 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
Austin Ziegler ha scritto:
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
···
On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Austin Ziegler 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.
<minisnip>
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 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.