my (@a,$b,%h) behaves like a function with infinte prototype [(\[@$%];\[@$%]\[@$%]...]

No references are taken. So that's both an inaccurate and a very complex way of thinking about it. It's much simpler to think of it as taking a list of variables.

(That's why I didn't understanding what he meant by flattening: Nothing can be flattened into variables.)

If parsing rules are different, so why not the behaviour in scalar context, too?

It's possible. The parser converts qw( ... ) into a list. It could convert my (...) into a list of simple my expressions. In fact, it does that already, but it does it specially so the code behaves as if my was a function.

But why would you want to make my() behave differently than foo(). That doesn't remove confusion or problems. It adds to them.

> No references are taken. So that's both an inaccurate and a very complex way of thinking about it. It's much simpler to think of it as taking a list of variables.

Well, you started claiming an analogy between builtin functions and named operators. :)

from Prototypes

Because the intent of this feature is primarily to let you define subr
+outines that work like built-in functions, here are prototypes for so
+me other functions that parse almost exactly like the corresponding b
+uilt-in.<P>

   1. Declared as Called as
   2.
   3. sub mylink ($$) mylink $old, $new
   4. sub myvec ($$$) myvec $var, $offset, 1
   5. sub myindex ($$;$) myindex &getstring, "substr"
   6. sub mysyswrite ($$$;$) mysyswrite $buf, 0, length($buf) - $off, 
+$off
   7. sub myreverse (@) myreverse $a, $b, $c
   8. sub myjoin ($@) myjoin ":", $a, $b, $c
   9. sub mypop (\@) mypop @array
  10. sub mysplice (\@$$@) mysplice @array, 0, 2, @pushme
  11. sub mykeys (\%) mykeys %{$hashref}
  12. sub myopen (*;$) myopen HANDLE, $name
  13. sub mypipe (**) mypipe READHANDLE, WRITEHANDLE
  14. sub mygrep (&@) mygrep { /foo/ } $a, $b, $c
  15. sub myrand (;$) myrand 42
  16. sub mytime () mytime
[download]

> But why would you want to make my() behave differently than foo(). That doesn't remove confusion or problems. It adds to them.

nope, don't think so. Already the fact that you can assign a list, i.e. my(LIST)=LIST is beyond the normal patterns of lvalue subs.

An operator working on lists of variables having a special behavior in scalar context is IMHO strange!

Cheers Rolf

Well, you started claiming an analogy between builtin functions and named operators. :)

"builtin function" is another name for "named operator". No analogy was made between the two.

I understand your point even less.

Already the fact that you can assign a list, i.e. my(LIST)=LIST is beyond the normal patterns of lvalue sub

How would changing my affect that statement?

I don't understand this point either.

An operator working on lists of variables having a special behavior in scalar context is IMHO strange!

No operator or builtin or sub can return more than value in scalar context. It simply makes no sense. The only reason you're in scalar context is because what will receive the value cannot handle more than one value.

map, sort, grep, reverse, and more all work on lists and behave specially in scalar context. What about keys, values, split, splice, m//g, s///g, and more whose primarily purpose is to return a list? They all return something else in scalar context.

I don't see what you find strange.