pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
meppl good night 00:39
mncharity ok... let's see... 01:29
mncharity g'night & 02:38
pugs_svnbot r20332 | putter++ | [STD_red] Very slightly improved parsing of regex literals.
diff: dev.pugscode.org/changeset/20332
lambdabot Title: Changeset 20332 - Pugs - Trac
ruoso nothingmuch, I think I came to a even cleaner solution to the "lax" signature matching thingy... 11:21
a pragma that redefines infix:<~~>(Object,Object)
pasteling "ruoso" at 195.23.92.2 pasted "example code for "typematch" pragma" (10 lines, 235B) at sial.org/pbot/30923 11:23
nothingmuch ruoso: seems hackish to me, the scoping is not as fine grained since it's no longer nestable inside an expression 12:29
it could be used to change the default I suppose
but i think £ is useful on its own too
ruoso trying hard to avoid additional signature features ;)
nothingmuch so implement Signature::Simple 12:30
and optimize to it
when the signature has no £ (likely 99% of the time) make it a ::Simple
and when it does, well... for now you just die with "TODO" ;-)
adding this to the context of the call makes analysing this harder too 12:31
you can't tell from just the foo(B.new) AST subtree what the bheavior will be
given the signature of B
you need to analyze it in the context of its entire lexical scope
and while this is in general well supported, it's still more work I think 12:32
anyway, dinner time
false alarm... not quite dinner yet 12:34
imagine you are someone writing the compile time type checker 12:35
instead of making this a simple, standalone body of code
that delegates the <<B.new>>.type to the param to check for compat
you now need to evaluate the compat cecking routine in an environment created during the tree traversal reaching the node 12:36
which is a lot more statefulness
ruoso er...
nothingmuch really dinner now
ruoso except that this pragma *can* actually be implemented
so the optimizer needs to be aware of it anyway
nothingmuch ruoso: why should the optimizer know about every degenerate case? 13:00
if the signature is finalized
nothingmuch then ~~ can't be overrideen in it 13:00
by an external pragma
instead you'd have to derive your own signature
i don't wnat to know how slow perl 6 will be if Signature ships open,basal by default ;-) 13:01
pmurias nothingmuch: my optimistic assumption is that metaprogramming will be kept inside BEGIN blocks, thus allowing running perl6 fast 13:05
nothingmuch pmurias: sometimes you want to give up speed for conciseness though
if you allow to override the definition of ~~ that is cokmpiled into Sig::Param::is_compatible on a runtime basis 13:06
that is an exceedingly difficult optimization
i would say making it impossible by default will make the 99% of the time case many times faster 13:07
than what the 99% case can be when its still possible by default
i think making 99% of the code a lot faster all the time, and 1% (probably less) sometimes very slow
vs. 100% of the code pretty fast, with a lot more effort
is a more realistic target 13:08
at the end there are no free lunches, of course
the question is how to get most of the lunches to be cheap without losing your sanity ;-)
pmurias & 13:09
ruoso nothingmuch, so we need the spec to explicitly forbid that... 13:10
the matching now is specced as ~~
and ~~ can be overriden...
nothingmuch i don't think you can write a lexical pragma to modify all definitions of a core op everywhere at runtime that easily 13:11
ruoso hmm... I'm pretty sure you can
nothingmuch IIRC it was mentioned that the global namespace is closed by default
that doesn't mean its not reopenable
either way I wouldn't lose sleep over this degenerate case 13:12
it seems to be a lot more work than just adding £ to sigs 13:13
hell, you can just subclass the param
and install a polymorphic parameter object in the sig that overrides is_compatible
seems a lot easier than changing the global definition of a class that affects everything everywhere just to negotiate one dispatch lexically 13:14
pmurias ruoso: you would have to undo all the optimalizations which depended on the way that opcode worked 14:26
ruoso pmurias, the thing is (and that's what I'm saying in a mail I've just sent to p6-lang), ~~ is not a "opcode" 14:32
it's a p6-level subroutine
and so is "isa" and "does"
and "like", when/if it is implemented 14:33
pmurias don't you just get a copy of the Prelude imported into *your* lexical scope at the start of the file
ruoso don't follow
pmurias from what i understand you wont to redefine the definition of ~~ everywhere right? 14:34
sort of local &infix:<~~> := sub {...}? 14:36
ruoso you *might*.... 14:38
pmurias s/wont/want 14:39
i'm not sure if it is possible to change (easily) the definition of for example &say globaly 14:41
ruoso I'm pretty sure it is 14:43
pmurias if only finding things in irc logs would be easier... ;) 14:44
it's not possible to add anything for sure 14:45
add to GLOBAL that is 14:46
ruoso: if it's possible then your pragma would be relativly simple to write, otherwise you would have to recompile a lot of stuff which should still be possible 14:48
ruoso the thing is that even if it is compiled, it's still "late dispatch"ed 14:49
which means that it's only resolved at call time
pmurias having an "early dispatch" pragma would be nice 14:52
Khisanth it would be a bit disappointing if you couldn't do that(since you could in p5) 15:00
ruoso but it's true that there might be some way of disabling that for more agressive optimization... 15:03
and even for sand-boxing, actually... 15:05
TimToady most operators are defined via Prelude, which means they're lexically scoped, and don't use the global namespace at all. 15:14
it should be easy to override your own ~~, but hard to override everyone else's 15:15
unless they agree to your dialect via declaration
pmurias Khisanth: do you have a use case for doing this at *runtime*? 15:21
ruoso TimToady, so redeclaring ~~ wouldn't affect the signature matching... 15:22
TimToady ruoso: that would depend on whether signature matching thinks it's using infix:<~~> or some underlying primitive 16:36
matching a signature against a capture is just one of the things ~~ does, so it could well be delegating that match to the underlying primitive used by ordinary sig binding 16:37
I expect this is rather orthogonal to the scope of ~~, which is intended as more of a dwim operator than a basic one 16:38
you're really talking about something more like .ACCEPTS at the lower level 16:40
in other words, it's a confusion of abstraction levels to think that overriding ~~ will change how signatures bind. 16:41
ruoso will re-re-re-read the specs... 16:42
TimToady you can't use multiple dispatch to implement multiple dispatch... 16:43
(not that ~~ is really multi dispatch anyway, it's a reversed single dispatch)
ruoso TimToady, I was going to implement mmd using mmd, but special-casing for the known low-level types... 16:49
ruoso in order to bootstrap 16:55
TimToady that's fine, just don't think of ~~ as the mmd operator. :) 17:10
ruoso TimToady, could you please point me to where ACCEPTS is documented? 17:23
TimToady various places in S03 17:28
ruoso TimToady, one last thing... during signature matching for mmd... does it: Capture.ACCEPTS(Signature) or Signature.ACCEPTS(Capture)? 17:42
ruoso later & 17:50
TimToady @tell ruoso the signature is the pattern, so the signature accepts the capture, which means it's the operation underlying Capture ~~ Signature (note reversed args from Signature.ACCEPTS(Capture)) 18:13
lambdabot Consider it noted.
cj quiet in here today 21:26
Auzon Yes, very. 21:27
pugs_svnbot r20333 | clkao++ | provide OP_bind_pad. 21:39
diff: dev.pugscode.org/changeset/20333
lambdabot Title: Changeset 20333 - Pugs - Trac
mncharity TimToady: STD.pm seems to be missing categories terminator and infix_circumfix_meta_operator . 21:44
mncharity TimToady: numbering... :) (1) token categories terminator and infix_circumfix_meta_operator are not defined; (2) S02 and the kp6 tests suggest =begin without an ident is ok, but pod_comment requires one. 21:50
mncharity (3) pod_comment looks like it would accept =begin foo\n=end foobar\n 22:12
Juerd Is there a list of things supported by Rakudo? 22:13
I really hate trial and error waay too much.

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!