> I don't see how you could pass something that could be flattened.

hmm  my (@a,$b,%h) behaves like a function with infinte prototype

sub my (\[@$%];\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%]\[@$%] and so on )

which avoids flattening.

OTOH the lvalue character can't be simulated for more than one value.

> > Well, my behaves different in several aspect to other buildins.

> A lot of builtins have unique parsing rules. (print, map, sort, system, our, ...) And?

The "And" is: If parsing rules are different, so why not the behaviour in scalar context, too?

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

I don't see any difference between

foo(bar(ARGS));
foo(my(ARGS));
[download]

bar(foo(ARGS));
my(foo(ARGS));
[download]

Why do you think my should behave differently than bar?

I've expressed no opinion on whether it should. I'm just observing it does.

Please elaborate. So far, you've only given examples of how you can't use my. There's no disputing there are limits. You didn't give any example of how it doesn't behave like a sub.

So far, you've only given examples of how you can't use my.

Let's see, I gave several examples where you either can't use my where you can use subs, or where my behaves different than subs do.

How much more differences do you need before you could imagine someone doesn't consider my to behave like a sub? Heh, I don't care one iota what you consider to be subs or not. I don't consider my to behave like a sub. And I've pointed out enough differences why I don't consider my to act like a subroutine call.