[ruby-core:32596] Parameter and Return Interface Specification (Was Re: Re: Proposal for Optional Static Typing for Ruby)

What about designing a Ruby-esque a way of specifying parameter and =
return interfaces?

I think that this would mean
* differentiating call interfaces based on runtime parameter typing
* specifying expectations for parameters and promises for returns

The first would be a simple way of creating complex DSL-style interfaces =
from a splat-type method interface.=20
The second would be an interface for querying methods to see if they =
return an object compatible with expectations.

Presumably these would not be determined at runtime, but would rather be =
specified by code. For instance (not a thoroughly considered exampled):

# method signature( string, :symbol, <any object>, { key =3D> data } )
def some_method
  parameters_define do=20
    parameter_set do
      parameter String, Symbol
      parameter String, Symbol
      parameter Object
      parameter Hash
    end
  end
  return_responds_to :method
  ...
  return return_object
end

I think that while Ruby is not inclined toward parse-time typing =
checking, runtime interface inquiry is most appropriate. It seems to me =
that the more we move toward integrating Ruby, the more we will need to =
treat Ruby not as a language with source/runtime programs, but as an =
active environment that we can at any point investigate as to state (the =
more we can treat Ruby elements as always-present, the more we are =
programming an ecology of organic objects rather than interfacing with a =
program). I am thinking something like (obviously way down the road) a =
fully-integrated IRB environment that pertains to daily OS operations as =
much as coding for application purposes. I think that Apple's =
development of Cocoa parallels Ruby in many ways in this senses, =
particularly in the use of singleton/factory patterns as controllers for =
class methods and singleton instances. It seems a small step from either =
instance to consider networks of runtime applications that can =
arbitrarily interface with one another in terms determined at runtime.=20=


It might be difficult at this point (where users are primarily human) to =
think about uses for such runtime interfacing, but I think 1. such uses =
will appear more as it is easier/more flexible to do so and 2. the more =
meta-programming becomes possible, the more it becomes possible to write =
automated/intelligent programs that act/interact in terms dependent on =
their environment.=20

This is by no means a solution/proposal at this point, but maybe enough =
to get some thoughts running?

Asher


On Sep 28, 2010, at 7:52 AM, Asher wrote:

> Martin,
>=20
> With respect, I think you're considering this backwards, attempting to =
adjust Ruby in order to address how you're used to dealing with =
language.=20
>=20
> As I see it, one of the major advantages of Ruby is its flexibility, =
insofar as it figures out for you many details (such as implicit =
typing). One of the major disadvantages of Ruby is that it has to figure =
out all of these details. In other words, attempting to satisfy both the =
advantages and disadvantages of typing in this way is likely to do =
little other than amplify the disadvantages of Ruby (primarily the =
underlying weight of the VM) as well as the disadvantages of typing =
(having to specify details everywhere, having to update details in =
multiple places for minor changes, etc.)
>=20
> So you say "reliable, powerful tools" - why does this correspond to =
typing in any way?=20
>=20
> I think instead we should be asking what "powerful" and "reliable" =
mean in a programming context where typing is not the primary emphasis. =
What is a hardened Ruby program? I think this is worth asking, but I =
don't think it's a question whose answer is barred by way of any =
relation to typing.=20
>=20
> Some languages (PHP?) have dealt with this by using "type hints", but =
I think this simply encourages the wrong approach, emphasizing explicit =
typing over patterns that are not type-reliant. For instance (as many =
web pages/blogs will attest), a common pattern for Ruby-newbies is first =
Class checking, and second method response checking. While there are =
(rare) appropriate applications for these tests, most of the time they =
are misplaced and are symptoms of a view of language that comes from =
somewhere other than Ruby.=20
>=20
> Perhaps we would be better served by talking about what sorts of tools =
we desire. "Reliable" is obvious enough, but what of "powerful"? How are =
we to define this aspect of tools, particularly regarding Ruby =
specifically?=20
>=20
> So some questions:=20
>=20
> 1. What tools should exist?
>=20
> 2. Which of these tools don't yet exist or should exist with better =
implementations?
>=20
> 3. What is the inherent relation of these tools to typing?
>=20
> I think that much of what we are dealing with here is what I would =
call a distinction between meta-programming languages and =
memory-programming languages. Ruby is not a memory-oriented programming =
language, but a meta- oriented programming language. The functionality =
of Ruby has far more to do with contingent context elaborated at a =
run-point in the program context than it does with the mapping of code =
structures to computer (memory) structures. In other words, the =
brilliance of Ruby is that the code is not about how the computer works, =
but is about how the objects work (which require no inherent relation to =
the computer itself or to their particular mode of storage in memory). =
This seems to me to deal first and foremost with "getting away" from =
types while nevertheless retaining the underlying benefits that types =
provide (albeit mostly invisibly).=20
>=20
> Best,
> Asher
>=20
>=20
> On Sep 28, 2010, at 6:53 AM, Martin Pilkington wrote:
>=20
>> Hi Matz
>>=20
>> Thanks for the reply. I full agree with you (and Alan Kay) that =
typing can be a pain, though due to benefits in more accurate and =
effective tools there are advantages to it. If there was a way to easily =
and reliably get tools as powerful as languages with static typing =
without the need for the typing then I'd be all for it as I love using =
duck typed languages and the freedom they give.
>>=20
>> I did consider structural typing and it could be a route to go down. =
Ultimately I'm just wanting a better way for me and others to build =
reliable, powerful tools for Ruby, regardless of how that is approached. =
I did hit a snag when considering structural typing though, which may be =
due to my relative inexperience with structural typing, so you might be =
able to help with a solution.=20
>>=20
>> Obviously structural typing is great at easily working out whether =
two objects are technically interchangeable, whether or not they =
conceptually are. However, while you can say that a String object is =
simply one that has methods +, <<, concat, length, split, sub etc, it's =
somewhat harder to say what the argument and return types of those =
methods are (of course that is a somewhat bad example given that the =
return values/types are given for the very base classes and their =
methods, but you get the idea). This is ultimately the main reason for =
me wanting some degree of pre-runtime typing (the return types more than =
the arguments) and I can't see any way to calculate these types without =
type inference, which itself I see snags with.
>>=20
>> I'm just wondering if you have any thoughts about getting this method =
type information? I could just be overlooking something that a fresh =
(and far more experienced with Ruby) pair of eyes can see, but I'm just =
struggling a bit with reliable ways to get the type info needed.
>>=20
>> Thanks
>>=20
>> Martin
>>=20
>>=20
>> On 27 Sep 2010, at 4:29PM, Yukihiro Matsumoto wrote:
>>=20
>>> Hi,
>>>=20
>>> In message "Re: [ruby-core:32585] Proposal for Optional Static =
Typing for Ruby"
>>>  on Mon, 27 Sep 2010 20:58:51 +0900, Martin Pilkington =
<[e-mail]> writes:
>>>=20
>>> |I know this is my first post on this list and that I'm relatively =
new to the Ruby community, and that this can be a somewhat controversial =
topic (as I've found by asking about it on the #ruby-lang channel).=20
>>>=20
>>> Short response:
>>>=20
>>> "I'm not against types, but I don't know of any type systems that
>>> aren't a complete pain, so I still like dynamic typing." - Alan Kay
>>>=20
>>> Static typing surely has its benefit, but on the other hand, Ruby =
the
>>> language strongly encourages duck typing, so that its type system
>>> should not hinder duck typing.  As a result, the type checking =
should
>>> be based on structural types, not nominal types.  I don't think your
>>> proposal cares about duck typing or considered structural type
>>> conformance.
>>>=20
>>> Although I like your <type> notation, that reminds me the scheme
>>> object system, iff we don't have to write them often.  I don't think =
I
>>> could stand to write <type> everywhere.
>>>=20
>>> 							matz.
>>>=20
>>=20
>>=20
>=20
>=20