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.
rakudo_svn r28021 | pmichaud++ | [rakudo]: 04:54
r28021 | pmichaud++ | * Fix Test.pm so that it reports skipped tests correctly.
Maghnus Will P6 support comefroms? 06:14
moritz_ what's a comefrom? ;-)
Maghnus Opposite of a goto.
moritz_ it supports caller(), which gives you information about who/what called your sub/method 06:15
ah, doesn't seem to be the same 06:17
Maghnus There was a link to them on the Wikipedia Continuations page, so I thought maybe they were related 06:18
possibly even useful
moritz_ I never felt the need for something like comefrom 06:21
Maghnus At a very abstract level, the idea reminded me of extension methods 06:22
bacek__ rakudo: say Failure + 1; 12:25
exp_evalbot rakudo r28021 No output (you need to produce output to STDOUT)
rakudo_svn r28023 | jonathan++ | [rakudo] Implement smart matching on junctions. Additionally, do some fixes to make say (1|2).WHAT work. 12:43
r28024 | jonathan++ | [rakudo] Fix name-o. 12:44
r28025 | jonathan++ | [rakudo] Make Mutable PMC aware of ro property. Also fix GC and memory leak in it. 12:45
r28026 | jonathan++ | [rakudo] Make is ro, is rw and is copy work on subroutine parameters. The default is now is ro, so trying to assign to a parameter not declared is rw or is copy will be an error. 12:47
r28027 | pmichaud++ | [rakudo]: 12:51
r28027 | pmichaud++ | * Fix optional argument forms of skip() in Test.pm. (bacek++)
moritz_ rakudo: class A { }; if A.new() { say "true" } else { say "false" } 13:20
exp_evalbot rakudo r28029 OUTPUT[get_bool() not implemented in class 'A'␤current instr.: '_block11' pc 37 (EVAL_11:19)␤
pmichaud oooh, I can fix that. 13:21
moritz_ probably one method in Object, right? 13:21
moritz_ pugs: class A { }; say ?A 13:22
exp_evalbot OUTPUT[␤]
moritz_ pugs: class A { }; say ?A.new
exp_evalbot OUTPUT[1␤]
moritz_ so method Bool should return True for objects and False for proto objects?
[particle] yes 13:23
pmichaud the default boolean checks definedness
so Failure returns false also
pmichaud S02: # The definition of .true for the most ancestral type (that is, the Object type) is equivalent to .defined. Since protoobjects are considered undefined, all protoobjects (including Object itself) are false unless the type overrides the definition of .true to include undefined values. Instantiated objects default to true unless the class overrides the definition. Note that if you could instantiate an Object it would be considered defined, and thus 13:25
moritz_ but why is it .true and not .Bool? coercion to $type is always done with method $type 13:26
pmichaud ..."always"?
why always?
consider .list 13:27
and .hash
this might not really be "coercion". It's "how an object is evaluated in boolean context" 13:28
moritz_ not always, but for all non-basic types 13:29
and even for Str
pmichaud is that indicated somewhere in the synopses? 13:29
(coercion to $type is always done with method $type) 13:30
moritz_ yes, I'm looking for the quote right now
pmichaud and again, I think this isn't necessarily a coercion but rather "evaluate in context"
moritz_ It is also possible (and often preferable) to specify coercions from the other end, that is, for a class to specify how to coerce one of its values to some other class. If you define a method whose name is a declared type, it is taken as a coercion to that type: 13:31
method Str { self.makestringval() }
from S13
pmichaud okay, but that doesn't mean that's the only way to do it
or that coercions are always done that way 13:32
moritz_ right, but IMHO if we already have a mechanism, we should use it
for sake of consistency
pmichaud I think that .true and .Bool are subtly different. .Bool probably calls .true by default.
just as .List probably calls .list by default.
anyway, that's really a question for p6l :-) 13:33
bacek__ rakudo: say 'hello' 13:34
exp_evalbot rakudo r28029 OUTPUT[hello␤]
pmichaud TimToady: does .ACCEPTS always return a Bool value? How about .ACCEPTS on a Junction -- Bool or junction of Bool? 13:37
moritz_ btw I see only two occurences of '.list' in the synopsis 13:38
diakopter I was wondering why yap6's parser was so slow.. then I made a source filter to strip all debug() statements (since many of them include Dumper()), and it's about 1/900 as slow. 13:40
moritz_ diakopter: you could have profiled it ;) 13:41
diakopter that can be next...
pmichaud moritz: .list is the method form of list(...)
it means to return the object in list context 13:42
moritz_ ok, so it's the same as @(...)
pmichaud yes.
moritz_ should really lern Perl 6 some day
diakopter moritz_: well actually, converting the interpreter to produce an AST instead of synchronously evaluating successful parses clears the last hurdle before adding a "longest-token-match" option to "alternate()", and also failed parsing handling/recovery/notification (syntax error). 13:43
so that's next
actually longest-token-match will be the default behavior, and first-match will be an option. I suppose last-match and shortest-match could be options as well :) 13:44
diakopter moritz_: also, the debug (really, trace) output is verbose _to_the_extreme_... for a 40-line source file it produces tens of thousands of indented trace reports. 13:54
moritz_: obviously that reveals a possibly-unoptimized algorithm, but someday someone can take a look at that. 13:56
(if necessary) :D
pugs_svnbot r20624 | diakopter++ | [yap6] some shortcut files for win32 users like me (when I'm at the office) 14:12
r20625 | diakopter++ | changes to remove one layer of string eval 14:15
diakopter there's a lot of potential for memoization (since the parsing is entirely functional-oriented), given some work to properly normalize each's parameters. 14:16
diakopter puts that in the TODO
pugs_svnbot r20626 | diakopter++ | [yap6] convert ./perl6 to generate the interpreter directly instead of \nthrough Interpreter.pm, eliminating the last string eval layer 14:24
diakopter whee; I'm using edit.com to write commit messages now. 14:36
pugs_svnbot r20627 | diakopter++ | [yap6] convert ./perl6 to accept a filename as the first argument
r20627 | diakopter++ | as an alternative to accepting input on STDIN...
r20627 | diakopter++ | This brings yap6 closer to being able to integrate into the evalbot
r20627 | diakopter++ | (more easily).
diakopter er, I meant convert to accept STDIN input as well as a filename argument (which it already supported). Also, I meant to say, *last* argument, not first. 14:37
pmurias diakopter: what do you plan to do with the AST once you generate it? 14:41
diakopter pmurias: shove it to elf? :) actually there's a lot that needs be done before that point. the parser needs to become aware of the/a type system (even if it's just the builtins or even just the bare-metal literals), so that it can properly identify which handlers to indicate in the AST. 14:46
pmurias diakopter: that was what i hoped ;)
rakudo_svn r28033 | pmichaud++ | [rakudo]:
r28033 | pmichaud++ | * Temporarily revert r28026 so that trunk works while I refactor
r28033 | pmichaud++ | parameter handling in a branch.
diakopter pmurias: I took a long look at STD.pm last night. 14:47
my first comment is that only parts of it are written (as if) for a recursive-descent parser. 14:48
pugs_svnbot r20628 | pmurias++ | [elf] 14:51
r20628 | pmurias++ | moosish variant works once again (not much testing though)
diakopter it's like it's trying to minimize the necessity of backtracking... but my thought about that is that Perl 6 probably has a LL(>5000) grammar, so I'm going to stick with the recursive-descent approach until demonstrated otherwise. Still, I have some fairly complete ideas of how to generate a recursive descent grammar (in MJD's syntax) from STD.pm. 14:53
pmurias p6 backtracks in a couple of places only 14:54
diakopter: you plan to generate the grammar instead of hand-porting it? 14:55
diakopter at first I'm hand-porting it.
to prove this concept, mostly.
vixey hard-porting what? (and to what) 14:55
pmurias vixey: STD in STD-in-perl5
diakopter STD.pm to pugs/misc/yap6/Perl6in5/Grammar/STD_hand.pm 14:56
MJD created a two-step recursive descent parser... I'm going to convert it to being mostly a one-step parsing system... in other words, the first tokenizing step is not going to be very useful. :) 14:57
diakopter in STD.pm, TimToady (or someone) comments that each rule should be able to produce a list of the beginning pattern of each possible match, and I'm considering how to do that in MJD's functional system, because I suspect that will greatly increase efficiency. 14:59
diakopter until each rule can automatically produce that list, the pattern (regex) can be hand-written of course. 15:00
rakudo_svn r28034 | pmichaud++ | [rakudo]:
r28034 | pmichaud++ | * Temporarily switch off of using Perl6Scalar until we figure out
r28034 | pmichaud++ | the assign/morph issue.
diakopter but that optimization step is a ways off. That is, if we discover that parsing Test.pm takes 90 million descents. 15:01
diakopter I'm just glad I finally have the time to work on this. I've been thinking about it for a year, but things finally slowed down at work sufficiently... (I'm a fix-stuff person, and I've finally stabilized things so I'm not so needed). 15:02
pmurias diakopter: how to you do longest token matching with recursive descent? 15:03
pmichaud diakopter: the longest token matching stuff is also described in S05 15:06
the purpose is more than "avoid backtracking", it also determines which rule to invoke when there are several possible alternatives 15:07
diakopter pmurias: MJD's alternate() routine generates the parsers that descend into the alternatives. Right now it just returns the first match. I'm going to add the option to descend into all alternatives and compare how much of the input is eaten by each successful parse. Each successful parse produces a candidate AST sub-branch, and the one that eats the most input is used. Of course, at some point in the branching descent, the ...
... entire input is eaten, so it will still be a "first match" system for a given entire compilation unit.. but..... that should be sufficient.
diakopter MJD is Mark-Jason Dominus, for those (if any) that were wondering. 15:09
pmichaud: does that sound okay in theory?
pmichaud except for the "entire input is eaten" part. the ltm algorithm actually has markers in the rule that indicate when to stop matching and select an alternative. 15:10
diakopter reads www.perlsix.org/syn/S05.html#Longes...n_matching again 15:12
lambdabot Title: S05
pmichaud basically, any subrule, closure, or cut marker in a regex terminates longest token matching at that point 15:13
pmichaud er, I misspoke about subrules 15:16
diakopter ok, so it still returns a successful AST candidate to alternate(), it just knows to pick up where it left off if its branch candidate gets selected. that should be straightforward with this continuation-based system. 15:16
pmichaud but closure, cut, ||, and a few other constructs indicate "this is the longest token for this branch"
diakopter got it 15:17
pmichaud I would also think that one wouldn't build/return an AST until after the branch is selected
diakopter but it would just do another parse to generate it...?
I mean, I don't know of another way to do it. 15:18
although, I guess I see your point, there will be a lot more failed branching than having to double parse everything.
pmichaud well, ideally it shouldn't have to do "another parse" to generate it 15:19
when the rule comes back with "this is the longest token", ideally it would also have a continuation that allows parsing to re-start from where it left off without having to do the reparse 15:20
or, there should be a way to call the rule saying "skip over the ltm stuff you already did and continue from there" 15:21
or, even better
when calling the rule asking for ltm, pass an option saying "I want your ltm". The rule can then do things very quickly without bothering to store subrules or captures
because it'll pick those up on the next "official" call. 15:22
that way ltm can also be done using a dfa, which can be much faster. 15:23
(and the dfa for a rule could be computed from all of the dfa's of its subrules) 15:24
[particle] and it can recover state and respond to "that ltm didn't work, give me the next longest" 15:25
diakopter I think (at first) my hand-coded grammar will try to avoid those referential aspects of STD, and just try to parse everything in one pass without the references. I realize that won't last forever.....
diakopter an SLR parser, in other words. Isn't it technically possible to create an SLR grammar/parser for every language that has a consistent grammar? 15:28
pmichaud I don't know.
diakopter oh, I see, the system you (and then [particle]) were describing would be a GLR parser. 15:30
sometimes.
moritz_ I don't think Perl 6 even is in CFL, but I'm not sure about it
at least here-docs aren't parsable in CFL 15:31
pmichaud I generally don't remember enough about parser categories to be able to speak about them, nor have I found trying to classify Perl 6 grammars/regexes to be particularly helpful. 15:32
pmichaud so I just tend to think of them as "turing machines" and then get back to writing code :-P 15:33
moritz_ which leads to the question: can a turing machine actually parse Perl 6? ;-)) 15:34
pmichaud I think yes.
vixey I hope so :(
I don't have anything better than a turing machine here :P 15:35
pmichaud "Perl 6: Better than a Turing machine!"
vixey :D
moritz_ offers the not-yet-built quantum computer
vixey oh they're capable of doing stuff before you turn htem on I think I read that 15:36
diakopter that is, is a given language a coherent language (there is only one possible way to interpret all possible inputs)? to answer that is to answer the halting problem...
pmichaud "Perl 6: When quantum hardware is available, we'll be ready for it."
moritz_ if we had weekly p6l summaries I'd offer that as the key quote
diakopter all *legal* inputs, I meant.
diakopter goes back to manually converting STD5.pm 15:38
pmurias moritz_: aren't quantum computers also turing machines? 15:39
imperfect ones that is 15:40
moritz_ pmurias: yes 15:41
pmurias: though they are indeterministic, and can solve NP-complete problems in O(n²) ;-) 15:42
diakopter heh. my tokenizer now has 3 categories: 'newline, identifier, and '.' 15:43
'newline', 'identifier', and '.'
masak moritz_: you're probably joking, but let me just say that quantum computers don't solve NP-complete problems in subexponential time 15:44
www.scottaaronson.com/blog/?p=198
lambdabot Title: 11 Shtetl-Optimized 17 􏿽xBB Blog Archive 31 􏿽xBB The Orion Quantum Computer Anti-Hype ...
TimToady you can't easily add precedence levels with recursive descent
and it complicates calculating the current set of expected operators 15:45
diakopter thinks about precedence levels
vixey I wish I had some faint clue about how they actually work 15:46
moritz_ masak: you're right, only some "hard" problems can be reduced like that
TimToady and Perl 6 isn't a single language, so how can it possibly be consistent. :)
pmichaud TimToady++
moritz_ "Perl 6, the first post-modern programming meta language" 15:47
diakopter TimToady: if each precedence level had its own construct constructor.... /me trails off
diakopter untrails off 15:48
pmichaud need lunch, bbiaw 15:48
diakopter ... then the operator() routine would recurse deeply all the possible precedence level detectors, identifying which one matched based on the recent matches 15:49
TimToady in theory, the language in use at any particular spot is immutable, but that doesn't necessarily minimize the amount of work to calculate a new parser from a previous parser
diakopter so, a tighter precedence would return sooner. hm. oooh, actually it's easier than that. 15:50
TimToady except that precedence parsing is not about absolute precedence levels, but relative between two or more operators 15:52
TimToady and if you're doing lookahead in the rules to see what the next operator is, that info has to be mixed into the LTM somehow so you match a token from the correct set of possible tokens expected by the surrounding context, which is dynamically determined by surrounding rules 15:55
diakopter but operator precedence doesn't need to be determined until AST-generation time, until then you can just assume left (associativity or otherwise). if a valid AST fails to produce from that branch, it backs up and tries another option. so, that would add another pass, essentially. 15:58
moritz_ but how do you determine what a valid AST is? 15:59
diakopter if it follows the precedence rules
moritz_ so would you have grouping parenthesis as part of the AST?
TimToady backtracking is generally an evil approach to parsing, at least for computers...
diakopter hey, that's namecalling
TimToady just channeling computers :) 16:00
diakopter har
TimToady people do it all the time, but look at you funny when they have to backtrack
diakopter routinely forgets which branches he's already tried
TimToady the hardware only supports parse trimming on a low level :) 16:01
diakopter moritz_: so basically the expression parser would be using the parsing engine only to do its own tokenizing, and then another pass would be done to iteratively establish which valid precedence was intended (if any!) 16:02
some leaf directions would have to be marked tentative, and others definite. 16:03
ancestry determination
TimToady STD5 does something slightly different, insofar as it uses the current parser to generate token sets, but uses a dfa to match the actaul tokens
though it doesn't really run the parser to get the longest tokens... 16:04
[particle] cheater
TimToady and yes, it would be nice to be writing in a language with continuations, so that you could just resume 16:05
diakopter if I understand it correctly, by longest-token-match, we mean longest-match
TimToady but Perl 5 ain't one of those languages without a lot of persuasion
[particle] even in the regex engine?
diakopter TimToady: MJD's functional grammar syntax does continuations.
TimToady that's what I call a lot of persuasion :) 16:06
diakopter heh
moritz_ and it still uses perl's stack internally
TimToady longest token != longest match (in the general case)
moritz_ which might be a problem with large parse trees
diakopter moritz_: yes, even with small inputs I get the "deep recursion" warning :D :D 16:07
TimToady as pmichaud(?)++ pointed out earlier, longest tokens stop at :: and {} and such
diakopter on anonymous subroutines
moritz_ diakopter: well, warnings can be disabled ;)
diakopter surely you'd have to rebuild perl to disable that warning....? anyone? 16:08
TimToady anyway, for STD5 I decided that the most expedient thing was simply to use the LTM to calculate what the fate of the recursive descent parser was going to be, and then just have the RDP avoid testing alternatives that are already fated 16:09
a continuation-based approach could also be made to work, I'm sure
but I'm also trying to minimize the amount of storage needed for a lexer because we're potentially generating quite a few of them, one for each sublanguage we run into 16:10
diakopter but with RDP, each sublanguage is just another option...? 16:12
TimToady I should stop calling them sublanguages, I suppose...
diakopter with its own context
TimToady language variants...
[particle] dialect? 16:13
diakopter more like sets of colloquialisms
moritz_ so is the "a derived grammar for each language variant" an "eat own dog food" approach?
TimToady you bet 16:14
[particle] grammar Perl6 isa POD6 isa Perl6Regex etc? 16:15
TimToady that's why I threw out all the old specialized quote parsing code and am working on building quote languages using mixins
[particle] s/isa/is/
TimToady well, so far it's mostly things built up over Perl6 16:15
and Regex is derived from Perl6, actually 16:16
(in the current formulation)
[particle] what about pod?
moritz_ [particle]: I think POD6 is better handled as a separate grammar, or mixing (or whatever)
POD and Perl 6 don't have that much in common
TimToady they're kinda co-grammars, if you will 16:17
[particle] yes, that's what i'm wondering about, for the perl 6 grammar, how do we express that it reads pod
or, is it that the compiler understands both grammars, but they're unrelated?
diakopter TimToady: I was thinking of detecting the stop character for quoting dialects and literally transforming the input back to bare metal format.
[particle] however, i think they're interrelated, in that you can have perl 6 in your pod and vice-versa
TimToady it's possible to pass parsers as parameters, which is how Regex currently knows how to parse the inside of {}
(well, Regex keeps the outer language in a context var, iirc) 16:18
diakopter: you mean, have the parser lie to itself? that's kind of a p5ish approach...
moritz_ [particle]: add POD6 to the ws token? 16:19
TimToady currently ws calls a stub pod parser, but it could certainly switch to any parameterized language it liked 16:19
diakopter sure, take the input string, fixup any escape graphs, declare a new subcontext, and dive in, using standard RDP from then on 16:20
TimToady that's why p5 is p5, and not p6
(to the first approx :)
p6 tries very, very hard to avoid any double parsing 16:21
Perl has developed, late in life, an allergy to lexers and parsers that fib to themselves... 16:22
diakopter late in *this* life
TimToady Perl 6's idea of "use strict" is one-pass parsing :) 16:23
modulo LTM trickery, of course. :)
and the couple places where the grammar backtracks to shoehorn a bit of extra overloading into the huffman coding... 16:25
my current feeling on quotes is that it's probably a mistake even to hardwire a stopper into the lexer, because users are likely to be fairly consistent about which characters they use for delimiters, so we don't have to generate *too* many quote dialects (probably) 16:29
TimToady (the currently checked in STD5 has a hardwired stopper, but that's probably going away, if my parameterized mixin roles (via eval) work out 16:30
)
pity that Moose doesn't do parametric roles yet...
stevan_ patches welcome ;) 16:31
we worked out how to do it with just types
but thats not interesting enough
TimToady sorry, I'm scared of p5 :)
stevan_ TimToady: try python, I hear it is cleaner
the trick is get a nice enough sugar layer and keep the meta-operations efficient 16:33
TimToady I suspect real generics in p5 would drive me mad(der) 16:34
so for now I'm just emulating with eval, the 1st Great Escape Valve of missing features 16:35
(along with BEGIN)
stevan_ :)
diakopter or anything else that causes another compilation unit 16:36
TimToady I don't suppose anyone has written B::QuasiQuoting yet... 16:38
pugs_svnbot r20629 | diakopter++ | [yap6] 16:40
r20629 | diakopter++ | eliminate another level of indirection by cleaning up some cruft.
TimToady I suspect the only sane way to add some of these features to p5 is to implement p6...
s/only sane/least insane/ 16:41
s/s/ss/
diakopter af[terminal] 16:46
pmichaud TimToady: I had two items in backscroll you might've missed (more) 16:48
#1 does .ACCEPTS always return a Bool? How about .ACCEPTS on a Junction -- a Bool or a junction of Bools ?
#2 Item is used as a type at S10:103, S10:146, S12:1703. Not urgent at all -- it just came up in conversation so I thought I'd ask. 16:49
TimToady shower & # thinking 16:50
pmichaud okay
no rush on them -- just want to make sure Rakudo gets .ACCEPTS right
(jonathan submitted a patch that raised the question.)
TimToady pmichaud: my suspicion on #1 is that .ACCEPTS isn't defined in Junction at all, and it just autothreads, so the junctional logic is handled by the eventual Bool context. On the other hand, the autothreader probably wants to know if it's running in Bool context so it can short circuit... 17:30
pmichaud TimToady: that was my suspicion as well. Thanks. 17:31
TimToady on the gripping hand, short-circuiting junctional logic is probably best handled by the types that are involved somehow, since the bare junctional logic has no clue which of the values are likelier to falsify
however, for now I think we can ignore that
Item is an odd fish; it sort of fuzzes into and out of existence like lists and captures 17:32
pmichaud right 17:32
TimToady if it is a type, it's whatever coercion to $ does 17:33
pmichaud okay
TimToady but that's hard to describe in terms of the rest of the type system
pmichaud right. It can be fuzzy for now -- I just wanted to make sure it was fuzzy.
TimToady it forces some degree of encapsulation of container types as non-container
TimToady whatever it is that prevents $x from interpolating an array even if $x contains one 17:34
pmichaud so, Item is the immutable form of Scalar? 17:34
TimToady maybe
pmichaud but it's more of a role than a class 17:35
TimToady hadn't thought of it that way, but it feels close to the truth
pmichaud basically it's the "not a container" role
but yes, formalizing that sounds tricky (in any real sense) 17:36
TimToady it's the I'm-just-a-plain-object-ignore-me role
pmichaud got it. that's enough of a working definition for me for now.
so, basically $x ~~ Item would be true, but VAR($x) ~~ Item would be false 17:37
anyway, I don't want to takk too much of your brainpower on it -- not terribly important. Figuring out list( a=>1, 2 ) is much more important. :-) 17:38
pmichaud s/takk/take/ 17:38
TimToady the bothersome thing is that scalar/list distinctions are close to Essence of Perl, and it would be nice to actually understand what that means... :) 17:41
pmichaud heh
pmichaud true. 17:41
TimToady there's something rather tagmemic going on here: "a container being used as not-a-container" 17:42
pmichaud well, for whatever it's worth, in Rakudo right now .item on a Scalar object returns the value inside the Scalar.
TimToady but that must be written VAR($x).item, surely? 17:43
pmichaud in Perl 6 that would be VAR($x).item is the thing held in $x
right :-)
[particle] why not VALUE($x) ?
pmichaud $x.item returns the value in $x
particle: .item refers to "item context" -- i.e., it's the thing you get with $($x) 17:44
[particle] VAR($x).item seems like it could just as well be $x.VARIABLE.VALUE or somesuch
pmichaud it does have a different meaning if $x is Match object or a Capture or somesuch 17:45
TimToady ALL YOUR CAPSLOCKS BELONG TO US!!!
spinclad my $y = VAR($x); VAR($y).item; # does this chase one or two levels of itemhood?
pmichaud $($/) ==> $/.item()
which is *not* the same as VALUE($/)
TimToady any method called on $x is automatically delegated to the item within $x 17:46
(unlike @x or %x, which keep the methods to themselves)
spinclad so $y delegates to $x, which delegates to its item
pmichaud TimToady: yes, I finally understood that relationship last week :-)
and thus my @a = 1; now works in Rakudo :-) 17:47
TimToady s/BELONG/ARE BELONG/ # grr, brainrot 17:50
cj TimToady: is there a keyword for c-style static variables? 18:28
TimToady cj: Perl 6 doesn't have C-style static variables, but you're probably wanting "state" variables instead. 19:12
cj TimToady: thanks :) 20:15
ron rakudo: my $a = 3; ($a + 2) = 9; say $a; 20:18
exp_evalbot rakudo r28038 OUTPUT[Method 'lvalue' not found for invocant of class 'PAST::Stmts'␤current instr.: 'parrot;PAST::Compiler;as_post' pc 2554 (src/PAST/Compiler.pir:684)␤
ron rakudo: my $a = 3; $a++ = 9; say $a; 20:19
exp_evalbot rakudo r28038 OUTPUT[4␤]
moritz_ perl -wle 'my $a = 3; $a++ = 9; print $a' 20:20
Can't modify postincrement (++) in scalar assignment at -e line 1, near "9;"
ron rakudo: my $a = 3; ($a +2) += 9; say $a;
exp_evalbot rakudo r28038 OUTPUT[3␤]
moritz_ rakudo: my $a = 3; say $a++
exp_evalbot rakudo r28038 OUTPUT[3␤]
moritz_ rakudo: my $a = 3; say ++$a
exp_evalbot rakudo r28038 OUTPUT[4␤]
ron In that last case ($a +2) += 9 you can seem to work around by setting is lvalue(1) for += like ++ -- seems harmless. Any objections ? 20:23
Setting lvalue(1) in grammer-oper.pg 20:24
moritz_ ron: try it, write a test, run spectest_regression
ron I did - seemed ok but didn't fix $a++ = 9 or $a++ += 9 20:27
moritz_ a partial fix is better than none ;) 20:28
cj TimToady: yeah, that was it. thanks again! 20:29
pmichaud rakudo doesn't totally keep track of rvalues yet 20:32
(as you can tell)
still working on getting our types and properties together.
ron I took a glance at t/operators/arith.t from pugs and didn't see relevant tests. If I look through the tests in more detail and don't see anything relevant should I try to submit some? 20:38
moritz_ ron: sure
[particle] ron: do you have a commit bit?
ron no 20:39
moritz_ time to get one ;)
[particle] we'll fix that now
moritz_ just /msg me your email address and desired nick name
[particle] sent email already
moritz_ (if different from "ron") 20:40
d'oh, I'm too slow
[particle] dunno if i sent it to the correct ron... but how many can there be? 20:40
ron ronaldxs at software-path.com 20:41
[particle] sent
how's things in newark?
Patterner Fine. I spent a year there during a weekend. 20:43
moritz_ [particle]++
meppl good night 21:03
pmurias pugs: sort(5,2,3,1) 21:53
exp_evalbot RESULT[(1, 2, 3, 5)]
pmurias &sort dosn't seem to exist according to S29, only being defined as a method 21:54
perl6: sort(5,2,3,1)
exp_evalbot kp6 r20629: OUTPUT[no method 'APPLY' in Class 'Undef'␤ at compiled/perl5-kp6-mp6/lib/KindaPerl6/Runtime/Perl5/MOP.pm line 345␤ KindaPerl6::Runtime::Perl5::MOP::__ANON__('HASH(0x824bd94)', 'APPLY', 'HASH(0x8e4dd78)', 'HASH(0x8e52370)', 'HASH(0x8e523c4)', 'HASH(0x8e52418)') called at
..compiled/perl5-kp6-mp6/lib/KindaPerl6/Runtime/Perl5/MOP.pm line 169␤ main::D...
..pugs: RESULT[(1, 2, 3, 5)]
..rakudo r28040: RESULT[[1, 2, 3, 5]]
..elf r20629: OUTPUT[Undefined subroutine &GLOBAL::sort called at (eval 14) line 3.␤ at ./elf_f_faster line 4492␤]
pmurias pugs: sort({$^b <=> $^a},5,2,3,1) 21:59
exp_evalbot RESULT[(5, 3, 2, 1)]
pmurias both sort({$^b <=> $^a},5,2,3,1) and sort(5,2,3,1) shouldn't be allowed 22:00
pmichaud pmurias: sort is at Functions.pod:866 22:15
pmurias pmichaud: it dosn't have is export 22:17
* doesn't 22:18
pmichaud but it's also not a method, either.
er, I should say 22:19
it's a sub
pmurias i haven't seen it before :(
pmichaud the "is export" is somewhat assumed, same for the other operators and subs in S29
our List multi sort( Ordering @by, *@values )
our List multi sort( Ordering $by = &infix:<cmp>, *@values )
diakopter boggles that the AS graphical debugger works with strawberry perl...! 22:20
breakpoints and variable watching is the coolest
pmichaud S29:63 says: In actual fact, most of the "functions" defined here are multi subs, 22:21
or are multi methods that are also exported as multi subs. Multi subs
are all visible in the global namespace (unless declared with a "my
multi").
pmurias thanks
sleep
&
TimToady hmm, that's actually not true anymore 22:30
pugs_svnbot r20630 | lwall++ | Note that multies aren't automatically global but are imported by Prelude now. 22:42
lichtkind in the S02 table is no information where __WARN__ __DIE__ are gone 23:11
Juerd After decades of abuse I think they deserve some time off. 23:13
Without people knowing their hideout's location. 23:14
Undisturbed and peaceful.
lichtkind :) 23:15
juerd i would not know them if i hadnt a reference but i just asked because i want to be all things to be complete 23:16
Khisanth there will no longer be any warnings that you are about to die? :) 23:18
Juerd I think __DIE__ is gone to CATCH
And the perlvert in me wants __WARN__ to be replaced by just wrapping the existing warn :)
lichtkind perlvert hihi nice word 23:19
i mean just add it to S02 that people know where there gone 23:20
ollright thanks and good night 23:29
Khisanth Juerd: hrm that would make more sense than having them in %SIG 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!