From: Asher Date: 2010-09-28T21:20:19+09:00 Subject: [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. 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, , { key => data } ) def some_method parameters_define do 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. 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. 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, > > 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. > > 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.) > > So you say "reliable, powerful tools" - why does this correspond to typing in any way? > > 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. > > 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. > > 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? > > So some questions: > > 1. What tools should exist? > > 2. Which of these tools don't yet exist or should exist with better implementations? > > 3. What is the inherent relation of these tools to typing? > > 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). > > Best, > Asher > > > On Sep 28, 2010, at 6:53 AM, Martin Pilkington wrote: > >> Hi Matz >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> Thanks >> >> Martin >> >> >> On 27 Sep 2010, at 4:29PM, Yukihiro Matsumoto wrote: >> >>> Hi, >>> >>> In message "Re: [ruby-core:32585] Proposal for Optional Static Typing for Ruby" >>> on Mon, 27 Sep 2010 20:58:51 +0900, Martin Pilkington writes: >>> >>> |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). >>> >>> Short response: >>> >>> "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 >>> >>> 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. >>> >>> Although I like your 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 everywhere. >>> >>> matz. >>> >> >> > >