From: itsme213 <itsme213@...>
Date: 2005-01-15T02:46:12+09:00
Subject: Re: Duck Typing and automated Conversions


"trans. (T. Onoma)" <transami@runbox.com> wrote
> On Friday 14 January 2005 10:31 am, itsme213 wrote:
> | Any ideas about how to do /*...*/, any other comments or suggestions,
> | welcome!
>
> I think this is the problem with your suggestion. You want to put a lot of
> info into this little /*...*/. Have you considered what it might be like?

I think it is better to consider the proposed functionality separately from
its concrete syntax. e.g. consider the signature information and how it
affects RDoc documentation; or information available via run-time reflective
access to do dynamic interceptors and adaptors; or performance; or whether
it contradicts Duck Typing or The Ruby Way.

That said, you are right that we need some idea of at least a strawman
concrete syntax to discuss examples; and you are also right that not all
cases should be crammed inline. I believe there are many options here. For
example, the starting point could be to draw a parallel between:
    - parameter binding for method call:
        def f(x,y)
        f(2,3) # bind x,y = 2,3 and execute f
    - variable binding for assignment,
        x,y = 2,3 # bind x,y = 2,3
    - built-in patterns (eg.*splat) and binding
        x, *y = 2, 3, 4 # bind x=2, y = [3, 4]
        x, y = *[2, 3] # bind x=2, y=3
        def f (x, *y) ...
    - match + bindings for regex =~:
        regex =~ obj # bind $1,$2...to matching bits of obj

So, with a disclaimer of /*duck_types_with_vars*/ is NOT concrete syntax:
- the primitive syntactic element of /*..*/ could be adapted from
   - var = expr, or regex =~ expr (or something else)
   - where expr impicitly has self = the caller parameter
- special cases ok e.g. Robert's str.to_s, *splat, **keys, &block
- simple cases of /*...*/ could appear inline in param list
- more complex cases could appear between def(...) and body
- type expressions without vars can be named, combined
- even type_with_var expressions can be named, combined
    t1 = /*expr-1*/
    t2 = /*expr-2*/
    t3 = t1 && t2
    t4 = t1 || t2
    t5 = all ducks with #m1(t1)
- such signatures could be used as 'interface' facility e.g. t5
    - with option to indicate *how* params may be used!
- even separate from def...though losing some functionality
    x.method(:foo).signature = /*...expr */

The win really would be that signatures would be more revealing and done in
a Ruby-standard way. Remember that the programmer always has the option of
deciding what he wants to include in signature info vs. exclude. As it is,
he can already exclude all signature info by simply writing every method as:
    def f *args

Florian Gross' Binding.of_caller could probably be used to prototype ideas
like this, but it would take someone considerably smarter than me (Florian?)
to explore this :-)