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

First. Thankyou for taking the time to respond to this. It is appreciated.

Aiui, if the leading candidates for a dispatch only use static nominal typing (specifying types like int, Int, Str, a class, role, etc. for their parameters) then resolution of which to finally pick is done at compile-time.

That implies that if I call a multi-sub defined to take (say) two Int vars; but I pass it integers embedded in ordinary scalars; then it will fail? What if the integers are being stored as strings in the PV of the scalar?

If Perl6 is to retain scalars; but people write their modules using Ints & Strs etc. for efficiency; then it either forces their users to also use Ints & Strs etc. or multi-subs will have to use runtime resolution.

Alternatively, I guess the programmers could add more multi-subs for each of the permutations of combinations of subscalar types and defined types; but that is a combinatorial nightmare.

Of course, this still leaves the gulf (an order of magnitude? two?) between the basic sub call performance of Rakudo and of perl.

Aiui there are tons of bog standard optimization techniques (speed and RAM usage) that still haven't yet been applied to Rakudo, NQP, and MoarVM. Aiui more of these optimizations are supposed to arrive this year but most will come in later years.

That's understandable, it took Java many years and iterations to sort out their performance problems; and they basically had to invent(*) (or at least, radically refine and generalise) JIT compilation to do it.

But my gut feel is that there are several Perl6 design elements Multi-subs, junctions, autothreading, to name but 3 -- that individually make writing an efficient runtime implementation exceedingly hard.

And writing a single VM to deal with all of those; plus the ability to introspect and reflect on everything including the kitchen sink; the neighbours dog; uncle Tom Cobbly an'all; makes for ... well, what we've seen till now.

I am aware smalltalk had a form of JIT before Java; and of course, LISP did it first; but Java refined it, generalised it, popularised it, and brought it to the main stream.

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^8: rough approximation to pattern matching using local (Multi Subs)

Replies are listed 'Best First'.
Re^9: rough approximation to pattern matching using local (Multi Subs)
by raiph (Deacon) on Feb 09, 2015 at 05:02 UTC
    Quick reminder for any visitors reading this:

    »»» This post is about the immature Perl 6, not the rock solid Perl 5 «««

    If Perl6 is to retain scalars; but people write their modules using Ints & Strs etc. for efficiency; then it either forces their users to also use Ints & Strs etc. or multi-subs will have to use runtime resolution.

    No. (Or, rather, the user doesn't need to know they're using Ints, Strs, etc.) 

    multi sub a ( Int $, Int $ ) {}
my ($foo, $bar) = 1, 2;
say $foo.VAR; says 'Any'
say $foo.WHAT; # says '(Int)'
a($foo, $bar); # call is resolved at compile time

    [download]

    No type is declared for the container $foo. So it's `of` type defaults to Any. This serves as a constraint on what can be assigned to $foo -- anything that is of type Any or a subtype (anything but Junction or Mu).

    The type of the contained value is distinct. In this case the compiler infers that it's an Int. An Int is a subtype of Any so the assignment is OK.

    Both of these types are known at compile time.

    The type info available at compile-time includes:

    • The types inferred by the compiler for literals;
    • The types defaulted to for multisub parameters for which no type is explicitly specified;
    • The types explicitly specified for multisub parameters, if any;
    • The types defaulted to for call args for which no type is explicitly specified;
    • The types explicitly specified by the caller, if any.

    Even if the coder calls multisubs without adding type info to their args the call will still be resolved at compile-time if there's enough type info available at compile-time.

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

[reply]
[d/l]

      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
[reply]
[d/l]
        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]

In Section Seekers of Perl Wisdom