If the '<>' is file input then the compiler obviously can't determine types ... so I'm guessing you meant something else.

No. You had it right the first time. It stands for file input; but could equally be any other source of untyped data: a database; a web form; and IPC from another program.

More importantly, in "Perl" and other dynamic languages, it could simply be a key/value pair from a hash: while( my( $key, $value ) = each %hash ) { a( $key, $value ); }.

In an early version of my current project, I wanted to do two-way lookup of pairs of values: lookup( name ) -> integer & lookup( integer ) -> name; and the cheapest, most efficient solution was to store each integer/name pairing both ways in a single hash.

This would be true for any language and compiler

Well no. Most languages supporting pattern matching subs force you to type inputs at source.

But in Perl, (Python, Ruby, ...), we're not hamstrung by a static typing system; and it is perfectly natural and normal to have scalars, and whole data structures of scalars that contain a mix of integers, reals and strings, and use them as strings or integers or reals willy-nilly and have the language DWIM.

So once again I say; Perl6 will either: a) fail if we pass generic scalars to library multi-subs defined in terms of specific types; or it b) will need runtime dispatching to DWIM.