Forum: Ruby lib for optional static typing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D67ca51e6025a5ed5282205e70379798?d=identicon&s=25 robert_kuzelj (Guest)
on 2005-12-05 14:08
(Received via mailing list)
hi,

before i begin a word of warning:
if you, after reading this post, feel the almost unbearable urge
to answer me; if you feel that my poor soul must be saved
from the evil soothing of static typedness; if you think i must
be enlightened to the wonderful world of dynamic typing...
PLEASE resist it!
make some breathing exercises or take a cold shower.
really i dont want to discuss the merrits of static vs. dymanic typing.


ok here is my question:
is there any lib where i could emulate attributes on methods
like there are some libs already now for python 2.4

@params(String, String)
@return(String)
def concat(_key1, _key2):
    return _key1 + _key2

that is something that allows for defining the parameters
and the return type and the corresponding checks at runtime.

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)

thank you

robertj
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 bob.news (Guest)
on 2005-12-05 14:16
(Received via mailing list)
robertj wrote:
> typing.
>
> that is something that allows for defining the parameters
> and the return type and the corresponding checks at runtime.
>
> 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)
>
> thank you
>
> robertj

There is a DbC sample implementation that might be able to do what you
want.

    robert
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 djberg96 (Guest)
on 2005-12-05 15:01
(Received via mailing list)
robertj wrote:
>
> that is something that allows for defining the parameters
> and the return type and the corresponding checks at runtime.
>
> 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)
>
> thank you
>
> robertj

http://raa.ruby-lang.org/project/strongtyping/

Regards,

Dan
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-05 15:05
(Received via mailing list)
Hi --

On Mon, 5 Dec 2005, robertj wrote:

> is there any lib where i could emulate attributes on methods
> like there are some libs already now for python 2.4
>
> @params(String, String)
> @return(String)
> def concat(_key1, _key2):
>     return _key1 + _key2
>
> that is something that allows for defining the parameters
> and the return type and the corresponding checks at runtime.

It sounds like you're more interested in class/module ancestry than
type.
You can always use is_a? (possibly lightly wrapped, if that makes it
feel
more "official" :-)  There are also things like the "StrongTyping"
module,
which (despite its name) is, as I understand it, essentially doing the
kind of ancestry-filtering you're interested in.

There's also been some work on type-matching in Ruby, though it's a
non-trivial problem.


David
__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!>
D67ca51e6025a5ed5282205e70379798?d=identicon&s=25 robert_kuzelj (Guest)
on 2005-12-05 17:53
(Received via mailing list)
ok,

that seems to handle most of my requirements also
i would prefer a more "declarative" approach.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-12-07 03:20
(Received via mailing list)
On 12/5/05, robertj <robert_kuzelj@yahoo.com> wrote:
> that seems to handle most of my requirements also
> i would prefer a more "declarative" approach.

You will, however, find that such a module and approach gets in your
way of writing quality Ruby code.

You may not want to debate the merits of static vs. dynamic typing,
but if you're wanting static typing, then Ruby may not be what you
really want. Aside from that, you may want to look at writing your own
mechanisms. There are things that I will have to be doing to encode
some "typing" information in a future version of PDF::Writer; examples
of how to do that *as appropriate for your domain* will be visible at
that point.

-austin
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-07 03:32
(Received via mailing list)
On Dec 6, 2005, at 8:17 PM, Austin Ziegler wrote:

> On 12/5/05, robertj <robert_kuzelj@yahoo.com> wrote:
>> that seems to handle most of my requirements also
>> i would prefer a more "declarative" approach.
>
> You will, however, find that such a module and approach gets in your
> way of writing quality Ruby code.
>
> You may not want to debate the merits of static vs. dynamic typing,
> but if you're wanting static typing, then Ruby may not be what you
> really want.

Amen!  I so agree.

I did my time in the Java trenches and I understand static typing
well.  Heck, every time I read another Design Patterns book, it takes
me a week to get back to coding idiomatic Ruby.  Nothing else feels
right though.

It really is a mindset change.  At least make sure you give it a try,
before you abandon the benefits.

Ruby was meant to be free and she'll fight you if you try to reign
her in.  ;)

James Edward Gray II
D67ca51e6025a5ed5282205e70379798?d=identicon&s=25 robert_kuzelj (Guest)
on 2005-12-08 18:58
(Received via mailing list)
<sigh>

thats the problem.
sometimes "dymamic guys" argue with as much
stubborness as the "static typing guys" do.
only the other way around.

fact is that sometimes "static" typing is
extremly helpful and sometimes it is in your way
as much.

the question imo not so much if static typing is useful
or if dynamic typing is useful
BUT when to use static typing.


ciao robertj
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 chneukirchen (Guest)
on 2005-12-09 11:25
(Received via mailing list)
"robertj" <robert_kuzelj@yahoo.com> writes:

>
> the question imo not so much if static typing is useful
> or if dynamic typing is useful
> BUT when to use static typing.

The *real* question is where to get a type-system that is flexible
enough to analyze non-runtime dynamic parts of Ruby without spraying
class names all over. :-)

This is left as an exercise for the reader.
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 james_b (Guest)
on 2005-12-09 16:24
(Received via mailing list)
Christian Neukirchen wrote:
>>fact is that sometimes "static" typing is
> class names all over. :-)
>
> This is left as an exercise for the reader.

BTW, there is a discussion on the Pragmatic Programmer mailing list
right now about the pros/cons of static typing.

http://groups.yahoo.com/group/pragprog/



James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - 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
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 chneukirchen (Guest)
on 2005-12-10 12:33
(Received via mailing list)
James Britt <james_b@neurogami.com> writes:

>>>the question imo not so much if static typing is useful
>>>or if dynamic typing is useful
>>>BUT when to use static typing.
>> The *real* question is where to get a type-system that is flexible
>> enough to analyze non-runtime dynamic parts of Ruby without spraying
>> class names all over. :-)
>> This is left as an exercise for the reader.
>
> BTW, there is a discussion on the Pragmatic Programmer mailing list
> right now about the pros/cons of static typing.

Except the archives are only accessible by members, which probably
read it already anyway. :-)
D67ca51e6025a5ed5282205e70379798?d=identicon&s=25 robert_kuzelj (Guest)
on 2005-12-10 16:15
(Received via mailing list)
>The *real* question is where to get a type-system that is flexible
>enough to analyze non-runtime dynamic parts of Ruby without spraying
>class names all over. :-)

that is certainly a point of view that many "typed" guys
would subscribe to.
the problem imo is not to define a "sound" typesystem
(as most static typing systems try to do and fail
regardless of the imense effort that has been put into)
but one that helps to define contracts on the borders of your
system without being restricting on the rest of the system.

the only language i know that did an excellent job on that
was VB (classic) where you could work mostly untyped
(if you wanted and you did not care bout performace).
whenever you wanted to release a COM-object you had
to define the types.
this was a very pragmatic approach.

ciao robertj
A70a5e80f81077fb5181b6104fffa891?d=identicon&s=25 batkins57 (Guest)
on 2005-12-10 17:45
(Received via mailing list)
On 12/10/05, robertj <robert_kuzelj@yahoo.com> wrote:
> system without being restricting on the rest of the system.
>
>

Common Lisp supports something like that.  All values are dynamically
typed by default (as in Ruby), but typing can be added to specific
areas where you need it.  The user can decide whether to have the
typing used only as a compiler hint to get faster code, and/or to have
it enforced so that an error will be signaled when an attempt is made
to store an object of the wrong type into that variable.

I'm not familiar with Visual Basic, but is it the case that all
objects will eventually be COM objects?  I was under the impression
that they're pretty separate concepts.  Doesn't seem that pragmatic if
I have to change my regular code to a COM object just to get typing.
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 djberg96 (Guest)
on 2005-12-10 17:49
(Received via mailing list)
robertj wrote:
> system without being restricting on the rest of the system.
>
> the only language i know that did an excellent job on that
> was VB (classic) where you could work mostly untyped
> (if you wanted and you did not care bout performace).
> whenever you wanted to release a COM-object you had
> to define the types.
> this was a very pragmatic approach.
>
> ciao robertj

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.

I'm actually not sure if I want this, though.  I know I've supported it
in the past, but I worry that Java/C/C++ programmers coming to Ruby,
fearing the removal of the static typing training wheels, might adhere
to this style too readily when it should only be used sparingly.

Regards,

Dan
682fff6db11e1a150d6ce17f3b862448?d=identicon&s=25 doug00 (Guest)
on 2005-12-10 17:58
(Received via mailing list)
robertj wrote:
> to define the types.
> this was a very pragmatic approach.

See also boo http://boo.codehaus.org/ which has both static
and dynamic typing.  http://boo.codehaus.org/Duck+Typing
It has some stuff borrowed from ruby like anonymous closures.

If you pass "-wsa" to the booc.exe compiler, it will use "end"
statements like ruby instead of python-like indenting (although
it still requires the redundant colon at the beginning of a block).
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-10 18:06
(Received via mailing list)
Hi --

On Sun, 11 Dec 2005, Daniel Berger wrote:

>
> In this example, x must be a String, while y can be anything.  In
> effect, optional typing.

s/typing/ancestry-checking/

> I'm actually not sure if I want this, though.  I know I've supported it
> in the past, but I worry that Java/C/C++ programmers coming to Ruby,
> fearing the removal of the static typing training wheels, might adhere
> to this style too readily when it should only be used sparingly.

I think there are two main problems with this kind of thing: first,
that it could short-circuit people learning about how type actually
works in Ruby; and second, that it might discourage more Ruby-esque
program design.  It looks like it adds something to Ruby, but it
doesn't (since is_a? is already available), and in practice perhaps
subtracts something.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 james_b (Guest)
on 2005-12-10 19:11
(Received via mailing list)
Doug H wrote:

>
>
> See also boo http://boo.codehaus.org/ which has both static
> and dynamic typing.  http://boo.codehaus.org/Duck+Typing
> It has some stuff borrowed from ruby like anonymous closures.


I believe JScript.net also gives the choice of dynamic/static typing.
(Since it also supports the open 'class', prototype run-time
modification, it strikes me as the most palatable of the .net languages)



James Britt

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - 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
461b1da26b6b198ef014235928576d81?d=identicon&s=25 kyosuke (Guest)
on 2005-12-11 00:09
(Received via mailing list)
Bill Atkins wrote:
> Common Lisp supports something like that.  All values are dynamically
> typed by default (as in Ruby), but typing can be added to specific
> areas where you need it.  The user can decide whether to have the
> typing used only as a compiler hint to get faster code, and/or to have
> it enforced so that an error will be signaled when an attempt is made
> to store an object of the wrong type into that variable.
Well, personally, I really like Common Lisp and its approach. But
concerning compiler hints...what about the Stalin Scheme compiler? I
recently started studying compiler techniques it uses and it almost
convinced me that there _is_ such a thing as the legendary "sufficiently
smart compiler". :-) I'm just wondering, if there is such a thing for
Scheme, would Ruby also benefit from such a kind of compiler? Such a
dynamic object model that Ruby uses is quite a beast to tame, on the
other hand, the optimizations that Stalin performs are nothing short of
a miracle. ;-)

Jakub
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 chneukirchen (Guest)
on 2005-12-11 01:26
(Received via mailing list)
Jakub Hegenbart <kyosuke@seznam.cz> writes:

> convinced me that there _is_ such a thing as the legendary
> "sufficiently smart compiler". :-) I'm just wondering, if there is
> such a thing for Scheme, would Ruby also benefit from such a kind of
> compiler? Such a dynamic object model that Ruby uses is quite a beast
> to tame, on the other hand, the optimizations that Stalin performs are
> nothing short of a miracle. ;-)

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".)
461b1da26b6b198ef014235928576d81?d=identicon&s=25 kyosuke (Guest)
on 2005-12-11 01:30
(Received via mailing list)
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. :-D 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
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 ruby-ml (Guest)
on 2005-12-11 04:33
(Received via mailing list)
On 2005.12.11 09:21, Jakub Hegenbart <kyosuke@seznam.cz> 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 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
32edd0717b3144d5c58a352d613abdc9?d=identicon&s=25 surrender_it (Guest)
on 2005-12-11 13:29
(Received via mailing list)
dblack@wobblini.net 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)
:)
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-12-11 15:08
(Received via mailing list)
On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> 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
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 james_b (Guest)
on 2005-12-11 15:25
(Received via mailing list)
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
http://www.artima.com/rubycs/ - 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
32edd0717b3144d5c58a352d613abdc9?d=identicon&s=25 gabriele renzi (Guest)
on 2005-12-11 19:23
(Received via mailing list)
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.
32edd0717b3144d5c58a352d613abdc9?d=identicon&s=25 gabriele renzi (Guest)
on 2005-12-11 19:32
(Received via mailing list)
Austin Ziegler ha scritto:
> On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> 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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-11 22:54
(Received via mailing list)
On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> wrote:
> Austin Ziegler ha scritto:
>> On 11/12/05, gabriele renzi <surrender_it@-remove-yahoo.it> 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
A6d3a37b5badfdd2f47655aa0e46604e?d=identicon&s=25 Eivind Eklund (Guest)
on 2005-12-12 17:15
(Received via mailing list)
On 12/5/05, robertj <robert_kuzelj@yahoo.com> 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 http://people.freebsd.org/~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.
32edd0717b3144d5c58a352d613abdc9?d=identicon&s=25 gabriele renzi (Guest)
on 2005-12-13 00:05
(Received via mailing list)
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>

> 	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.
This topic is locked and can not be replied to.