Re^13: rough approximation to pattern matching using local (Multi Subs)

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?" )}

Comment on Re^13: rough approximation to pattern matching using local (Multi Subs) Select or Download Code

Replies are listed 'Best First'.
Re^14: rough approximation to pattern matching using local (Multi Subs) by BrowserUk (Patriarch) on Feb 10, 2015 at 04:28 UTC
the only feature that theoretically and actually results in run-time multisub resolution is 'where constraints'. I guess you forgot about this one:If the '<>' is file input then the compiler obviously can't determine types ... until run-time. already. Now I remember why I disengaged. You argue like a politician; servicing your own agenda, and never actually answering the question. Cheers. 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]

Replies are listed 'Best First'.

Re^14: rough approximation to pattern matching using local (Multi Subs)
by BrowserUk (Patriarch) on Feb 10, 2015 at 04:28 UTC

the only feature that theoretically and actually results in run-time multisub resolution is 'where constraints'.

I guess you forgot about this one:If the '<>' is file input then the compiler obviously can't determine types ... until run-time. already.

Now I remember why I disengaged. You argue like a politician; servicing your own agenda, and never actually answering the question. Cheers.

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]