lib for optional static typing

[robertj]

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

 

[Robert Klemme]

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

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

robert

 

[Daniel Berger]

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

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

Regards,

Dan

 

[David A. Black]

Hi --

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
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!>

 

[robertj]

ok,

that seems to handle most of my requirements also
i would prefer a more "declarative" approach.

 

[Austin Ziegler]

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

 

[James Edward Gray II]

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

 

[robertj]

<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

 

[James Britt]

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.

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

 

[robertj]

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

 

[Bill Atkins]

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

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.

 

[Daniel Berger]

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

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

 

[Doug H]

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.

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

 

[dblack]

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

 

[James Britt]

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

 

[Jakub Hegenbart]

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

 

[Jakub Hegenbart]

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

 

[Eero Saynatkari]

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

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

 

[gabriele renzi]

(e-mail address removed) ha scritto:

Hi --




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)

 

[Austin Ziegler]

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