in reply to Re^9: rough approximation to pattern matching using local (Multi Subs)
in thread rough approximation to pattern matching using local

Warning: Pseudo-P6 :) 

multi sub a ( Int $, Int $ ) {}
multi sub a ( Int $, Str $ ) {}
multi sub a ( Str $, Int $ ) {}
multi sub a ( Str $, Str $ ) {}

my( $x, $y ) = <>.split' ';

a( $x, $y ); ## How do you determine which multi-sub to invoke at comp
+ile time?

[download]
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
  • Comment on Re^10: rough approximation to pattern matching using local (Multi Subs)
  • Download Code

Replies are listed 'Best First'.
Re^11: rough approximation to pattern matching using local (Multi Subs)
by raiph (Deacon) on Feb 09, 2015 at 08:48 UTC
    If the '<>' is file input then the compiler obviously can't determine types (and thus have a chance of figuring out which sub to call) until run-time. This would be true for any language and compiler so I'm guessing you meant something else.

    If the '<>' is quote words; and Rakudo implemented the `val` feature from the spec; and it was applied (either implicitly or explicitly) to the quote words after splitting; and if at least one of the values was recognized as an Int, and the other as either an Int or a Str; then the result would be compile-time resolution to the more fitting candidate.

    (Read the first paragraph of Literals and maybe the :val modifier etc.)

    »ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )

[reply]
      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.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
[d/l]
        Parameter coercers just landed in Rakudo's main branch. Parameter coercers allow multisub defs like this: 

        multi sub a(Str(Any) $s, Int(Any) $i) { }

        [download]

        This will compile-time match a call to 'a' with any pair of args, no matter what their types (well, not values of type Junction or Mu because they aren't subtypes of Any). At run-time the actual args would be coerced to Strs.

        I previously linked to stuff about val() but I get the sense you didn't read it (which is fair enough -- I link a lot :)). The val() feature is not yet implemented in Rakudo (it is in Niecza I think) but the block on that is due to be lifted in the next couple weeks and it is about as significant as parameter coercers so I've decided I'll mention it here now. With val() processing: 

        my @args = <1   foo   2.3   bar>;
.WHAT.say for @args; # (Int) (Str) (Num) (Str)

        [download]

        val() is automatically applied in various contexts. Presumably the relevance of this to the current exchange is as obvious as parameter coercers. That is, val() would also facilitate nice matching semantics with compile-time resolution.

        (Aside: any slang can define it's own val() thus nicely packaging up automated conversion of literals in any language in to P6 types. I can totally see a JSON DSL doing that for JSON literals, for example.)

        Perl6 will either: a) fail if we pass generic scalars to library multi-subs defined in terms of specific types

        It would be a bug in the Rakudo compiler if it passed generic scalars to a library multisub defined in terms of specific types and yes, that would be a fail, presumably a segfault or somesuch. I am not aware of any such bug.

        Perl6 will either: b) will need runtime dispatching to DWIM.

        At this point in my research in to this, and more importantly testing my hypotheses against Rakudo, I've tentatively concluded that the only feature that theoretically and actually results in run-time multisub resolution is 'where constraints'.

        »ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom