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. |
|||
00:06
bacek joined
00:10
bacek left,
bacek joined
00:19
Picotero_ joined,
Picotero_ is now known as Picotero
00:20
Picotero is now known as Maghnus
00:40
wknight8111 left
00:44
lambdabot left,
lambdabot joined
00:53
simcop2387 is now known as Guest39177
00:56
qu1j0t3 joined
00:59
wknight8111 joined
01:01
qu1j0t3 is now known as FurnaceBoy_
01:04
FurnaceBoy left
01:13
FurnaceBoy_ is now known as FurnaceBoy_dinne
01:58
kanru left
02:01
c1sung joined
02:12
jhorwitz left
02:19
ron left
02:52
ting joined
02:54
ting left
02:58
alester joined
02:59
ting joined
03:01
FurnaceBoy_dinne is now known as FurnaceBoy
03:15
rorpug joined
03:20
qu1j0t3 joined
03:23
qu1j0t3 is now known as FurnaceBoy_
03:27
FurnaceBoy left,
Alias_ joined
03:28
FurnaceBoy_ is now known as FurnaceBoy
03:38
pbuetow_ joined
03:48
agentzh left
03:49
agentzh joined,
pbuetow left
03:55
justatheory left
04:03
rakudo_svn left
04:04
rakudo_svn joined
04:23
ting_ joined
04:24
alc joined
04:28
FurnaceBoy left
|
|||
rakudo_svn | r28021 | pmichaud++ | [rakudo]: | 04:54 | |
r28021 | pmichaud++ | * Fix Test.pm so that it reports skipped tests correctly. | |||
05:08
justatheory joined
05:09
jan__ joined,
jan__ is now known as jan
05:22
alanhaggai joined
05:38
alester left
05:44
araujo left
05:50
justatheory left
05:52
wknight8111 left
06:02
armagad joined
06:03
Auzon left
06:13
sri_work joined
|
|||
Maghnus | Will P6 support comefroms? | 06:14 | |
moritz_ | what's a comefrom? ;-) | ||
Maghnus | Opposite of a goto. | ||
06:14
ting left
|
|||
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 | |
06:43
meppl joined
06:47
bacek left
06:48
melgx joined
06:52
iblechbot joined
06:54
edpratomo joined
06:57
cosimo joined
07:01
alanhaggai left
07:04
alanhaggai joined
07:20
Ched- joined,
Ched- left
07:22
Ched- joined
07:30
Auzon joined
07:39
alanhaggai_ joined
07:40
alanhaggai left,
sri_work left,
sri_work joined
07:44
sri_work left,
sri_work joined
07:45
sri_work left,
sri_work joined
07:49
sri_work left,
sri_work joined
08:17
alanhaggai_ left
08:23
jiing left
08:29
alanhaggai joined
08:38
masak joined
08:45
edpratomo left
08:47
elmex joined
08:49
avar left
08:56
polettix joined,
cornelius_ left
08:57
rorpug left
09:23
pbuetow_ left
09:29
jiing joined
09:30
bacek__ joined
09:32
bacek_ left
09:36
masak left
09:50
yahooooo left
09:52
bacek_ joined
09:54
bacek__ left
10:09
sri_work left
10:12
bacek__ joined
10:14
alc left,
yahooooo joined
10:17
alanhaggai left
10:19
chris2 joined,
alanhaggai joined
10:27
bacek_ left
10:28
wknight8111 joined
10:56
poletti joined
10:57
polettix left,
poletti is now known as polettix
11:11
Maghnus_ joined
11:14
lambdabot left
11:15
jiing left,
lambdabot joined,
jiing joined
11:16
iblechbot left,
wknight8111 left
11:19
poletti joined
11:20
polettix left
11:23
masak joined
11:25
poletti is now known as polettix
11:28
Maghnus left
11:29
polettix left,
polettix joined
11:31
melgx left,
melgx joined
11:32
lichtkind joined,
polettix left
11:33
polettix joined
11:34
polettix left
11:35
polettix joined
11:55
chris2 left
12:18
jhorwitz joined
|
|||
bacek__ | rakudo: say Failure + 1; | 12:25 | |
exp_evalbot | rakudo r28021 No output (you need to produce output to STDOUT) | ||
12:41
kanru joined
12:42
FurnaceBoy joined
|
|||
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++) | |||
12:56
avar joined
13:03
Auzon left
13:05
FurnaceBoy is now known as FurnaceBoyAway
13:18
IllvilJa left
13:19
iblechbot joined
|
|||
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 | |
13:21
wknight8111 joined
|
|||
moritz_ | probably one method in Object, right? | 13:21 | |
13:22
jan left
|
|||
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 | |||
13:24
FurnaceBoyAway is now known as FurnaceBoy
|
|||
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 | |
13:26
alc joined
|
|||
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 | |||
13:29
cmarcelo joined
|
|||
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" | ||
13:30
edpratomo joined
|
|||
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 | ||
13:33
melgx left,
eternaleye left
|
|||
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 | ||
13:49
halner joined
13:50
alanhaggai_ joined
13:53
sscaffidi joined
|
|||
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 | |||
14:00
avar left,
avar joined
14:03
avar left
14:09
IllvilJa joined,
avar joined
|
|||
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 | |
14:25
alc left,
kanru left
14:30
bacek__ left
14:32
mofino joined
|
|||
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 | |
14:39
rdice joined
14:40
pmurias joined
|
|||
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 | ||
14:49
ludan joined
|
|||
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 | |
14:53
alester joined
|
|||
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. | |||
14:55
ludan left
|
|||
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 | ||
14:59
justatheory joined
|
|||
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 | |
15:00
elmex left
|
|||
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 | |
15:02
kanru joined
|
|||
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 | |
15:03
pbuetow joined
|
|||
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. | |||
15:09
ispy_ joined
|
|||
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 | |
15:15
alanhaggai_ left
|
|||
pmichaud | er, I misspoke about subrules | 15:16 | |
15:16
alanhaggai_ joined
|
|||
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..... | ||
15:25
alanhaggai left
15:26
edpratomo left
|
|||
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 | |
15:33
jan__ joined
|
|||
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 '.' | |||
15:44
alanhaggai_ left
|
|||
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 | ||
15:48
kanru left
|
|||
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 | |
15:53
alanhaggai joined
|
|||
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 | |
15:57
kanru joined
|
|||
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 | |||
16:01
FurnaceBoy is now known as FurnaceBoyAway,
FurnaceBoyAway left,
polettix left
|
|||
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 ;) | ||
16:07
Psyche^ joined
|
|||
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/ | ||
16:15
masak left
|
|||
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 | |
16:19
Patterner left,
Psyche^ is now known as Patterner
|
|||
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 | ||
16:30
jjore is now known as zz_jjore,
zz_jjore is now known as jjore
|
|||
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 | |
16:38
cjfields joined
|
|||
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/ | |||
16:42
lichtkind_ joined
16:43
bacek joined,
lichtkind_ left
|
|||
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.) | |||
16:52
nipotaway is now known as nipotan
16:59
lichtkind left
17:00
Patterner left
17:01
Psyche^ joined,
Psyche^ is now known as Patterner
17:02
zamolxes left
17:03
eternaleye joined
17:18
justatheory left
17:26
schmalbe joined
17:27
xinming joined
|
|||
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 | ||
17:32
ispy_ left
|
|||
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 | ||
17:34
FurnaceBoyAway joined
|
|||
TimToady | whatever it is that prevents $x from interpolating an array even if $x contains one | 17:34 | |
17:34
FurnaceBoyAway is now known as FurnaceBoy
|
|||
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 | ||
17:38
araujo joined
|
|||
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 | ||
17:41
sscaffidi_ joined
|
|||
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 | ||
17:48
sscaffidi left
|
|||
TimToady | s/BELONG/ARE BELONG/ # grr, brainrot | 17:50 | |
18:07
FurnaceBoy is now known as PebkacBoy
18:12
PebkacBoy is now known as FurnaceBoy
18:16
kanru left
18:21
FurnaceBoy is now known as FurnaceBoyAway
|
|||
cj | TimToady: is there a keyword for c-style static variables? | 18:28 | |
18:29
mofino left
18:30
mofino joined
18:38
justatheory joined
18:52
sri_work joined
18:57
cjfields left
19:01
dominiko joined
19:05
sscaffidi__ joined
19:08
vixey left
|
|||
TimToady | cj: Perl 6 doesn't have C-style static variables, but you're probably wanting "state" variables instead. | 19:12 | |
19:23
sscaffidi_ left
19:26
braceta joined
19:27
sscaffidi__ left
19:28
sscaffidi joined
20:09
ron joined
|
|||
cj | TimToady: thanks :) | 20:15 | |
20:17
cjfields joined,
dduncan joined
|
|||
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 | |
20:27
dominiko left,
schmalbe left
|
|||
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. | |||
20:36
cjfields_ joined
|
|||
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 | |||
20:40
jan____ joined,
braceta left
|
|||
[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? | |||
20:41
Alias_ left
|
|||
Patterner | Fine. I spent a year there during a weekend. | 20:43 | |
moritz_ | [particle]++ | ||
20:43
pochi joined
20:47
rdice left
20:51
jan__ left
20:52
lisppaste3 left,
Auzon joined
20:53
lisppaste3 joined,
cjfields left,
lisppaste3 left
20:55
cjfields_ left
20:58
ron left
21:00
rdice joined
21:03
FurnaceBoyAway is now known as FurnaceBoy
|
|||
meppl | good night | 21:03 | |
21:03
lisppaste3 joined
21:06
meppl left
21:07
alanhaggai left
21:17
jhorwitz left
21:22
dduncan left
21:32
japhb left
21:34
kst` left
21:35
kst joined
21:38
rdice left
21:44
jan____ left
21:45
jan______ joined
|
|||
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ā¤] | |||
21:55
japhb joined
|
|||
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 | |
22:06
polettix joined
22:09
justatheory left
22:10
cjfields joined,
cmarcelo left
|
|||
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 | |||
& | |||
22:21
pmurias left
22:22
alester left
|
|||
TimToady | hmm, that's actually not true anymore | 22:30 | |
22:30
iblechbot left
22:35
Limbic_Region joined
22:39
eternaleye left
22:41
eternaleye joined
22:42
cjfields left
|
|||
pugs_svnbot | r20630 | lwall++ | Note that multies aren't automatically global but are imported by Prelude now. | 22:42 | |
23:11
lichtkind joined
|
|||
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 | ||
23:29
lichtkind left
23:32
eternaleye left
23:36
pbuetow left
23:40
Maghnus_ is now known as Maghnus
|
|||
Khisanth | Juerd: hrm that would make more sense than having them in %SIG | 23:49 | |
23:51
justatheory joined
|