svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com Set by avar on 16 November 2006. |
|||
00:02
buetow joined
00:07
Psyche^ is now known as Patterner
|
|||
putter | anyone around? | 00:07 | |
luqui | yeah | 00:08 | |
putter | I'm puzzling over release backends. It looks like the current candidates are p5, parrot, hs(?), whatever vm someone writes and emitter for. that sound about right? | 00:09 | |
And of those, the only one which could conceivably not be mostly written in p6 is hs, yes? | 00:10 | ||
luqui | I'm not really sure what you're talking about... | 00:12 | |
are you wondering what to call the backends for the release? | |||
putter | It Xmas. We have a releasable perl6. There seem several possibilities. Its vm could be p5, parrot, ... | 00:15 | |
00:16
cognominal joined
|
|||
putter | Though I think question is whether anything by a hs-based p6 might not be implemented in p6 itself. At one time self hosting was said to be a post 6.0 concept. | 00:16 | |
But it looks like the only current senario where that seems plausible is a hs-based release. | 00:17 | ||
I'm looking for a reality check, plus any comments like "selfhosting is now speced for 6.0", or "hs-based release has been removed from consideration". | 00:18 | ||
or even "vm is now required to be p5-based for compatibility/deployment reasons". | 00:19 | ||
any idea? | |||
luqui | as far as spec goes | ||
I think it's whichever one happens | |||
we would like it to be parrot based | 00:20 | ||
putter | k | ||
ok | |||
thanks | |||
00:27
nipra joined
00:30
nipotaway is now known as nipotan
00:37
mako132_ joined
00:40
diakopte1 joined,
diakopte1 left
01:02
lyokato joined
01:04
b00t joined
01:11
autark_ joined
|
|||
putter | Anyone know if www.perlfoundation.org/gc/grants/20...posal.html is still the parrot roadmap? | 01:12 | |
lambdabot | Title: The Perl Foundation | ||
01:18
lisppaste3 joined
|
|||
luqui dunnos | 01:20 | ||
putter | tnx | ||
luqui | putter, i searched the meeting notes for "roadmap", and nothing consequential came up | 01:23 | |
so either it's still in effect, or it has been gradually phased out without anybody noticing :-) | |||
01:24
lisppaste3 joined
01:34
diakopter joined
01:41
shobadobs joined
01:43
shobadobs left
01:44
rashakil joined
|
|||
putter | luqui: lol. my thanks. | 01:46 | |
sigh. dsl's without a full language - just dandy until you hit the inevitable screw case. :/ | 01:56 | ||
revised www.vendian.org/mncharity/Temporary...leteme.png and .dot | 02:20 | ||
& | 02:22 | ||
02:24
lisppaste3 joined
|
|||
luqui | that's a nice graph. it's motivating ;-) | 02:25 | |
02:43
penk joined
02:45
vel joined
02:55
ProperNoun joined
03:15
mdiep joined
|
|||
luqui | @tell putter what can I do to help on mp6/kp6? | 03:16 | |
lambdabot | Consider it noted. | ||
03:17
b00t joined
03:26
mdiep joined
|
|||
luqui | @tell putter whoops, fglock is doing that stuff, not you, right? hmm, I'll ask him | 03:27 | |
lambdabot | Consider it noted. | ||
luqui | @tell fglock what can I do to help on mp6/kp6? | ||
lambdabot | Consider it noted. | ||
03:43
leed joined
03:51
mako132_ joined
03:52
Aankh|Clone joined
04:36
nipra joined
04:47
nperez joined
05:00
thestarslookdown joined
06:15
BooK joined
06:22
GabrielVieira2 joined
06:33
avarab joined
06:46
avarab_ joined
06:48
avarab_ is now known as avar
07:11
ilogger2 joined
07:15
Aankh|Clone joined
07:33
avarab joined
07:39
iblechbot joined
07:43
avarab_ joined
07:46
xinming joined
08:01
Aankhen`` joined
08:30
spx2 joined
08:37
Lunchy_ joined
09:04
elmex joined
09:29
ruoso joined
10:03
takesako__ joined
10:16
mj41 joined
10:19
fglock joined
|
|||
masak | c2.com/cgi-bin/wiki?MultiMethods | 10:22 | |
lambdabot | Title: Multi Methods | 10:23 | |
fglock | luqui: re kp6 - right now, it would be nice to have someone review the design decisions | 10:32 | |
lambdabot | fglock: You have 2 new messages. '/msg lambdabot @messages' to read them. | ||
fglock | putter: re Data::Bind - it looked like a problem with perl itself, and there was a bug report to p5p | 10:33 | |
10:55
yves joined
|
|||
svnbot6 | r15077 | fglock++ | kp6 - added 'Assign' to the grammar | 10:56 | |
r15078 | fglock++ | kp6 - fix last commit | 10:59 | ||
11:07
xinming joined
11:15
xinming joined
|
|||
svnbot6 | r15079 | fglock++ | kp6 - added ChangeLog | 11:17 | |
fglock | re S06: how does an anonymous our-subroutine work? it can't be added to the namespace | 11:27 | |
11:29
f0rth joined
|
|||
fglock | also re S06: s/package GLOBAL/module GLOBAL/ | 11:31 | |
11:33
cmarcelo joined,
avarab_ is now known as avar
|
|||
fglock | re S02: how about replacing 'package' with 'namespace', to avoid confusion with p5 'package' | 12:01 | |
12:53
ofer0 joined,
Limbic_Region joined
|
|||
svnbot6 | r15080 | kudra++ | Corrected spelling of a word | 13:06 | |
r15081 | fglock++ | kp6 - added a Perl5-emitter plug-in | 13:15 | ||
pasteling | "evalbot_r15080" at 194.145.200.126 pasted "Pugs build failure" (375 lines, 20.9K) at sial.org/pbot/22428 | 13:19 | |
Juerd | Oh my... evalbot pastebots :) | 13:22 | |
Incredibly clever :) | |||
rgs | when will it begin to propose patches :) | 13:23 | |
Juerd | Or just commit them :P | ||
13:25
buetow joined
|
|||
svnbot6 | r15082 | fglock++ | kp6 - added kp6-perl5.pl script - compiles kp6 to perl5 | 13:30 | |
13:30
weinig joined
13:32
iblechbot joined
13:42
gnuvince joined
13:45
thepler joined
14:09
[particle] joined
14:13
VanilleBert joined
|
|||
masak | ?eval [ 'a' .. 'z', 0 .. 9 ].pick(10).join() | 14:14 | |
evalbot_r15082 | "etk2pr1oxv" | ||
masak | very well | ||
Juerd | pick takes an argument. Heh. | ||
masak | but pick(10) doesn't put them back, does it? | ||
Juerd | What do you mean by "put back"? | ||
?eval ~~['a'..'z',0..9].pick:10 | 14:15 | ||
masak | random selection with/without replacement | ||
evalbot_r15082 | Error: ā¤Unexpected "~~['"ā¤expecting program | ||
Juerd | ?eval ~~(['a'..'z',0..9].pick:10) | ||
evalbot_r15082 | Error: ā¤Unexpected "~~(['"ā¤expecting program | ||
Juerd | ?eval ~['a'..'z',0..9].pick:10 | ||
evalbot_r15082 | Error: ā¤Unexpected ":10"ā¤expecting term postfix or operator | ||
masak | if I want replacement, I have to do this: | ||
Juerd | ?eval ~['a'..'z',0..9].pick: 10 | ||
evalbot_r15082 | "w k f h 8 j o y t u" | ||
masak | ?eval ( { ['a' .. 'z', 0 .. 9 ].pick() } xx 10 ).map:{ .() }.join() | ||
evalbot_r15082 | "8g5w3muf20" | ||
masak loves p6 | |||
Juerd | What's the difference? | ||
masak | slight, but there | 14:16 | |
Juerd | Which is the difference? | ||
:) | |||
masak | in the latter, I could get the same letter twice | ||
in the former, I never will | |||
Juerd | Ahh | ||
masak | hence "with replacement" | ||
like an urn, you know :) | |||
Juerd | ?eval ~['a'..'z'].pick(26).join | ||
evalbot_r15082 | "shunzcmjtpofixqgldkvbaeryw" | ||
Juerd | That ~ wasn't needed :) | 14:17 | |
masak | yep, all there | ||
Juerd | ?eval ['a'..'z'].pick(52).join | ||
evalbot_r15082 | "fmwydzeuatonqrlcbjighkpxvs" | ||
masak | heh | ||
can't fool pick | |||
Juerd | Too bad | ||
?eval { ['a'..'z',0..9].pick } xx 10 | |||
evalbot_r15082 | ({Syn "block" {App &pick (Syn "\\[]" {Syn "," {App &infix:.. (: ā¤ "a", "z");ā¤ App &infix:.. (: 0, 9)}}: )}}, {Syn "block" {App &pick (Syn "\\[]" {Syn "," {App &infix:.. (: ā¤ "a", "z");ā¤ App &infix:.. (: 0, 9)}}: )}}, {Syn "block" {Ap | ||
masak | yow | 14:18 | |
you need to eval them | |||
with .() | |||
s/eval/apply/ | |||
Juerd | Then I'd still expect 10 subs. | ||
Or is this how pugs stringifies closures? :) | 14:19 | ||
14:19
vel joined
|
|||
masak | guess so | 14:19 | |
Juerd | ?eval { ['a'..'z',0..9].pick } xx 10 >>.() | ||
evalbot_r15082 | Error: ā¤Unexpected ">>.()"ā¤expecting operator | ||
masak | I think the >>ops are broken | 14:20 | |
been so a while now | 14:21 | ||
prove6 t/operators/hyper.t has a few :todos in it | 14:22 | ||
14:25
chris2 joined
14:26
[particle] left
14:30
weinig is now known as weinig|bbl
14:37
theorb joined
14:46
nipra joined
14:47
elmex_ joined
14:51
theorb is now known as theorbtwo
14:52
jferrero joined
14:53
[particle] joined
14:56
bonesss joined
14:59
fglock joined
15:24
jferrero joined
15:30
hexmode joined
|
|||
hexmode | km;/ | 15:31 | |
15:35
fglock_ joined
15:40
fglock joined
15:44
xinming joined
|
|||
TimToady | pick has an optional boolean parameter specifying :repl | 15:47 | |
not implemented though | |||
15:48
CardinalNumber joined
|
|||
TimToady | and "package" is the Perl word for "namespace" | 15:48 | |
I don't see any reason to make another alias for that. | |||
masak | TimToady: :repl, great | 15:52 | |
TimToady | I do kinda wish I could say ['a'..'z',0..9].[rand(*) xx 10] though | ||
?eval ['a'..'z',0..9].[map {rand 32}, ^10] | 15:53 | ||
evalbot_r15082 | ["h", "e", "b", "e", "x", 4, "q", 5, 0, "h"] | ||
TimToady | ?eval ['a'..'z',0..9].[map {rand 32}, ^10] | ||
evalbot_r15082 | ["b", "h", "a", "y", "e", "e", "q", 3, 0, "t"] | ||
TimToady | that works | ||
er, except it should be 36... :/ | 15:54 | ||
[particle] | of course, that's base 36 | 15:55 | |
so, can you get the size of the list inside the selector? | |||
TimToady | the list might not even be generated yet | 15:56 | |
[particle] | of course it would make it unlazy | ||
TimToady | ?eval ['a'..'z',0..*].[map {rand 36}, ^10] | ||
15:56
xinming_ joined
|
|||
evalbot_r15082 | pugs: out of memory (requested 1048576 bytes) | 15:56 | |
TimToady | oops | ||
[particle] notes, 'stop saying "of course"' | |||
TimToady | if @a[*;1] has * meaning all of the current dimension, then maybe +* is the size of the current dimension. | 15:59 | |
not quite sure if ['a'..'z',0..9].[map {rand 32}, ^10] | 16:00 | ||
er | |||
not quite sure if ['a'..'z',0..9].[map {rand +*}, ^10] would work though | |||
[particle] | i think it needs something explicit to act upon | 16:01 | |
TimToady | well, I'm not gonna think about that much. this morning I'm much more worried about how we carry the longest-token rule through a grammar consistently. | 16:04 | |
I'm not sure the <%foo|%bar|%baz> notation is sufficient, quite. | |||
16:05
diakopter joined
|
|||
[particle] | where does it fall down? | 16:05 | |
TimToady | several ways | 16:06 | |
the inheritance problem could be worked around saying %.baz instead of %baz | |||
16:06
diakopter left
|
|||
TimToady | and saying that if you have "rule baz", it can be used as a hash | 16:06 | |
in which case it is required to be able to cough up a table of its initial tokens as a set of keys | 16:07 | ||
16:07
diakopter joined
|
|||
TimToady | there's also problems in the followup to the initial token, however | 16:07 | |
at the beginning of a statment, for example, you are in a superposition of wants | 16:08 | ||
statement_control | |||
declarator | |||
prefix | |||
term | |||
etc. | |||
some of those have to fire off additional rules | |||
the hash allows a rule for the value of the hash | |||
but offhand I don't see how to recognize a prefix or term and fire off the operator precedence rule | 16:09 | ||
there's a token lookahead problem in general | |||
most recursive descent parsers assume a tokener with one token lookahead | 16:10 | ||
but the definition of token depends on our current state. | |||
and the tokens that are legal in a particular parser state | 16:11 | ||
may be specified not just by a top set of %grammatical_categories but by various subrules | |||
[particle] | to be clear, <%foo|%bar> is a true superposition (junction), and not logical-or | 16:12 | |
TimToady | you need the transitive closure of all the head tokens of all the rules. | ||
not a junction | |||
it could be any character there to indicate a sequence of hashes | |||
<%foo+%bar> would work as well | |||
[particle] | you're right, not a junction | ||
TimToady | the point is that the hashes as a whole follow longest token | 16:13 | |
[particle] | do the keys of %foo get precedence over %bar | ||
TimToady | while ties are broken in favor of the earlier hash | ||
[particle] | ok, i see | ||
longest token overall | |||
with stable sort | 16:14 | ||
TimToady | so it's a bit like the MMD policy that a "my multi" can hide a particular long name, but other long names can be pulled in from outside | ||
but if we have to go as far as interrogating each head rule for its initial tokens, then the hash notation is superfluous | |||
all we need is something like [ :longest <a> | <b> | <c> ] | 16:15 | ||
[particle] | sure, but it's much shorter | ||
it's almost as if the operator is spelled |% | |||
TimToady | or a different | | ||
yes | 16:16 | ||
|+ maybe | |||
[ %statement_control |+ %declarator |+ <op_prec_parser> ] | 16:17 | ||
[particle] | that stands out better visually | 16:18 | |
TimToady | though probably %.foo form instead for inheritance ease | 16:19 | |
and then the derived grammar doesn't have to temporize the hash for a lexical scope | 16:20 | ||
[particle] | oic. yes, that works. | ||
it makes the syntax a little clunky, but for good reason | 16:21 | ||
[ %.stmt_ctrl |+ %.decl |+ <opp> ] | |||
TimToady | actually, declarator is just another term, so it belongs down in opp as well. | 16:24 | |
we could finesse it for Standard Perl without the transitive property by making sure that statment_control is always an identifier | 16:25 | ||
but if someone were to add a punctuational statement_control, then we don't have the safety of whitespace anymore | |||
and it should really abide by the longest token rule, even if the longest token has to bubble up out of the <opp> rule. | 16:26 | ||
oh, which also has to be parameterized by its terminator, so another strike against using a hash for that. | |||
the other approach would be to use a set of hashes to peek ahead and figure out, the call <opp> with "pos" before the peeked token. | 16:28 | ||
16:28
kanru joined
|
|||
TimToady | but that doesn't seem as clean | 16:28 | |
s/the call/then call/ | |||
[particle] | what if jumping between parser types (rec-desc, opp, custom) is undefined behavior in hash combinators | 16:30 | |
TimToady | problem is we'd have to use different hashes for the same thing in different contexts | ||
so %prefix in the opp would have to just parse the operator, but at statement level would have to parse the whole expression | 16:31 | ||
[particle] | that's no good :( | 16:32 | |
TimToady | and I think it's just a lot niftier if the rule engine can calculate the transitive differences from a DRY specification | ||
than if we have to copy stuff around | |||
[particle] | agreed. | ||
[particle] goes to get wet | |||
TimToady | but it does seem to call for |+ or some such. | 16:33 | |
yeah, ich auch. & | |||
16:49
CardinalNumber is now known as ProperNoun
16:54
CardinalNumber joined
|
|||
svnbot6 | r15083 | fglock++ | kp6 - working 'hyper-to-map' transform | 17:01 | |
17:13
ashleyb joined
17:26
GabrielVieira joined
17:46
fglock joined
17:54
xinming joined
18:09
ProperNoun joined
|
|||
TimToady | I have majorly bitten the bullet. | 18:13 | |
see p6l for change of | semantics to longest token. | |||
now we use || for old | semantics | |||
[particle] | saw that | 18:14 | |
TimToady | for a while it was in the transitional form where only :ratchet reversed the meaning, but I decided consistency was more important with how | and || work outside | ||
and we get || for free because null patterns are illegal | 18:15 | ||
[particle] | that paragraph is a bit dense. an example might help | ||
gaal | say, $x in "for @list -> $x { ... }" is always my, right? is there a way to specify it otherwise? | ||
TimToady | it's a formal parameter | 18:16 | |
gaal | not that having it available is necessarily a good thing, but the one use case i'm thinking of is if you want to look at the last iterator value if you break early from the loop. | ||
TimToady | so you can do anything to it that you could do to the $x in "sub ($x)" | ||
gaal | hmm, i don't see how that fact can be used to change the storage type | 18:17 | |
[particle] | $OUTER::x? | ||
TimToady | while my $x = =@list {...} | ||
gaal | yeah, okay. :) | 18:18 | |
TimToady | my $x = first {...}, @list | 18:21 | |
gaal | oh, that was a yeah of assent, not sarcasm :-) | 18:22 | |
TimToady | np | 18:23 | |
gaal | (hmm, typed affirmative calculus) | ||
TimToady | my $x = @list.first: {...} | 18:24 | |
I think I like this language. :) | |||
kolibrie | timtowtdi, obviously | ||
gaal | hee | ||
TimToady | anyone care to hack .first into Functions.pod as a variant of grep? | 18:26 | |
18:28
avar joined
|
|||
kolibrie | the Little Red Hen must be baking bread | 18:39 | |
nothingmuch | the giant will eat her any moment | 18:40 | |
TimToady | "Not I" said the Little Fluorescent Green Pig. | 18:41 | |
stevan looks in the fridge and sees that all the blue ice cubes are gon | 18:42 | ||
18:44
larsen_ joined,
[particle] joined
18:45
bernhard joined
|
|||
svnbot6 | r15084 | lwall++ | Added first function. | 19:02 | |
19:04
neonse joined
|
|||
kolibrie notes that TimToady is not a Little Fluorescent Green Pig | 19:08 | ||
19:13
CardinalNumber joined
|
|||
svnbot6 | r15085 | fglock++ | kp6 - cleanup traverse/visitor | 19:13 | |
fglock | the sun here was just like this: www.geol.ucsb.edu/faculty/sylvester...ges/18.jpg | 19:17 | |
lambdabot | tinyurl.com/y8k8sj | ||
19:32
ashleyb joined
19:38
CardinalNumber is now known as ProperNoun
19:39
ziggy joined
|
|||
ziggy | hello, just a quick complete noob question: is there any tutorial/book teaching perl6? and i don't mean bits and pieces, something coherent and complete | 19:41 | |
Juerd | No, not yet | 19:42 | |
[particle] | perl 6 design isn't coherent and complete yet | ||
ziggy | hehe, guess i'll have to wait another 365 days :( | ||
Juerd | No, christmas is before then. | 19:43 | |
ziggy | last christmas and the one before that i heard the same :D | 19:45 | |
[particle] | one day maybe you'll believe it ;) | 19:47 | |
ziggy | how did you guys learn perl6? | ||
[particle] | by writing it. seriously. read the specs, and write some tests. | 19:48 | |
ziggy | wow | ||
[particle] | the tests are all written in perl6 | ||
wanna help? | |||
ziggy | so there are specs? | ||
Juerd | ziggy: I learned Perl 6 by reading Apocalypses, and trying to stay up to date after that | ||
ziggy: But if you start today, I would recommend that you read only the Synopses. | |||
[particle] | spec.pugscode.org | 19:49 | |
lambdabot | Title: Official Perl 6 Documentation | ||
Juerd | ziggy: See topic :) | ||
[particle] | ziggy: want a commit bit, so you can help? | ||
Juerd | ziggy: And/or access to feather, so you can try before you "buy"? :) | 19:50 | |
ziggy | wow, not so fast, let me chew a few synopses, try pugs, and then i'll ask if i consider myself usefull :) | ||
what's feather? | 19:51 | ||
10x for the link | |||
Juerd | ziggy: feather is a machine | ||
[particle] | ziggy: anyone can get a commit bit, even you | ||
Juerd | ziggy: People who want to try or work on Perl 6 (that includes Pugs) can get a shell account. | ||
ziggy: This was initially because many people found it hard to compile Pugs, as GHC is rather demanding during compilation. | 19:52 | ||
ziggy | nice, too bad i can't use it, because i've got a lame isp that drops 20% packets and ssh is so sloooooow | ||
i have no alternative, i must compile it myself | |||
Juerd | Good luck, then! :) | ||
ziggy | what do you mean by "demanding"? | ||
Juerd | It's not that hard, but it takes some time. | ||
ziggy: It uses lots of RAM and CPU. | |||
(The first time you compile it, that is. Subsequent compiles are much faster if not much was changed) | 19:53 | ||
ziggy | aren't there any binaries available? | ||
Juerd | There are some, but they're releases, and always out of date. | 19:54 | |
ziggy | ah, ok | ||
Juerd | There is also feather.perl6.nl:8080/runpugs/ if you want to try simple stuff (not entire programs) | 19:55 | |
lambdabot | Title: Run Perl 6 Now -- in your browser! | ||
Juerd | ?eval 1 + 5 # This works too, but please don't use it a lot :) | ||
evalbot_r15085 | 6 | ||
ziggy | wow, nice bot :P | ||
?eval say "hello" | 19:56 | ||
evalbot_r15085 | OUTPUT[helloā¤] Bool::True | ||
19:57
ofer0 joined
|
|||
[particle] | ?eval "hello".say | 19:57 | |
evalbot_r15085 | OUTPUT[helloā¤] Bool::True | ||
[particle] | perl6++ | 19:58 | |
ziggy | say is a string class method? :D | ||
[particle] | ?eval 4.say | 19:59 | |
evalbot_r15085 | OUTPUT[4ā¤] Bool::True | ||
[particle] | everything is an object | ||
ziggy | can you add methods to builtin classes, like in Ruby? | ||
[particle] | yes | 20:00 | |
ruby's older sister just got an extreme makeover :) | |||
ziggy | ok, you convinced me to read the specs :P | 20:01 | |
[particle] | you need a commit bit. msg me your email address | 20:02 | |
ziggy | ugh, i can't, i have to register a nick first | ||
[particle] | /msg nickserv identify <some_passwd_here> | 20:03 | |
hrmm, maybe i can start a private chat... | |||
20:04
ziggy is now known as Ziggy6
|
|||
TimToady | you can always use the "foo at whatever dot where" approach... | 20:06 | |
Juerd | TimToady: Which is utterly ineffective. | ||
[particle] | Ziggy6 msg'd me successfully. bit sent. | ||
Juerd | TimToady: Spammers also like Perl and its regexes :) | 20:07 | |
Ziggy6 | thanks, i got the email | ||
20:08
polettix joined
|
|||
kolibrie | Ziggy6: after you checkout pugs, add yourself to the AUTHORS file | 20:08 | |
Khisanth | [particle]: you can also set a mode so unregistered people can send you messages | ||
[particle] | how can i cpan upload from feather? | 20:09 | |
Juerd | [particle]: I don't understand the question. | ||
[particle] | i need to upload parrot-0.4.8.tar.gz to cpan | ||
it's on feather | |||
i'm on windows, using putty | |||
Juerd | [particle]: There are several ways. | ||
[particle]: You can use a command line utility for it, there are several on cpan | 20:10 | ||
[particle]: You can create an SSH tunnel and use the web interface | |||
[particle]: You can use w3m for the web interface | |||
[particle]: Easiest is probably to put the file in your ~/public_html, and have PAUSE download it from there | |||
[particle] | ah, yep, will do | ||
first, lemme make sure ithe tar is working | 20:13 | ||
gaal | [particle]: also, on the putty d/l page you'll find many ssh-based command line tools, eg for scp and sftp etc. | ||
[particle] | thx, gaal, i'll look at that, too | ||
gaal | also there's the cpan-upload tool, which is great when you're like me and find the most bugs in your code immediately after releaseing it | 20:14 | |
[particle] | i figured i'd release 0.4.8_01 first for sanity check | ||
gaal | I've done !cpa:p and then ^04^05 (or similar) more than once... | 20:15 | |
[particle] | besides, i'm not sure if i have proper rights to upload parrot yet | ||
20:17
cognominal joined
20:25
trym joined
20:32
fglock joined
|
|||
TimToady | fglock: hello, I hope the new | semantics will not cause you much heartburn. :) | 20:33 | |
It means you don't have to implement <%foo|%bar|%baz> as a special case. :) | 20:34 | ||
merely as a general case. | |||
since <%foo> | <%bar> | <%baz> is now guaranteed to behave the same. | 20:35 | ||
20:37
Ziggy6 left,
pmichaud joined
|
|||
pmichaud | TimToady: ping | 20:38 | |
[particle] | pmichaud: he was just here, i think he's hiding behind something | 20:40 | |
20:41
luqui joined
|
|||
pmichaud | okay | 20:41 | |
I have a ton of questions on the latest S05 changes :-) | 20:42 | ||
TimToady whistles | |||
pmichaud | oh wait, do I hear him? | ||
TimToady | It is pitch dark. If you proceed you are likely to be eaten by a grue. | 20:43 | |
luqui | I, also, have a ton of questions on the latest S05 changes | ||
Well, it's only one question, actually, but it weighs a ton | 20:44 | ||
TimToady | cool, fire at will, just don't fire at me. | ||
pmichaud | well, I'll start with the simple one first -- does @foo act like @foo[0] | @foo[1] | ... or @foo[0] || @foo[1] || ... ? | ||
[particle] thinks TimToady must be very far away, because he's hiding behind a spec | 20:45 | ||
TimToady | Seems like | would be nice | ||
pmichaud | I agree :-) | ||
it would then match %foo | |||
TimToady | then you don't have to sort it | ||
pmichaud | or at least they would tend to act more similarly | ||
TimToady | on the other hand, how do you then write the ordered one? | ||
luqui | that does have implications for infinite lists... | ||
pmichaud | the other question I have is more about the implementation description in S05 | 20:46 | |
TimToady | k | ||
pmichaud | the "list of initial constant strings" has to be a runtime decision, yes? | 20:47 | |
TimToady | luqui: is that your 2000lb question? | ||
luqui | no | ||
I expect it is similar to pmichaud's coming question | |||
so depending on what you were asking, yes | |||
pmichaud | i.e., in order for a rule to report back on the initial constant strings of an initial subrule, we'd have to know what grammar we're in at the time the match is being performed | ||
TimToady | yes, that's correct | 20:48 | |
but I see it much like mmd optimization | |||
pmichaud | why then we do we need to return the initial list? Couldn't we just have the rule report back "here's the initial constant string that I can match"? | ||
rephrasing | 20:49 | ||
why then we do we need to return the initial constant strings as a list? Couldn't we just have the rule report back "here's the longest initial constant string that I can match"? | |||
TimToady | doesn't allow for much optimization | ||
pmichaud | I'm not sure we're going to get much optimization anyway, since we have to determine it at runtime | 20:50 | |
luqui notes that that's how parsec does it | |||
TimToady | people will change the string to search much more often than the grammar used to search it | ||
luqui isn't sure how fast parsec is | |||
pmichaud | so, we could compile the table of initial constant strings at runtime | 20:51 | |
i.e., each rule maintains a list based on the grammar of the match | |||
TimToady | then you just merge those as you know the connections | ||
assuming lists are presorted longest to shortest | 20:52 | ||
pmichaud | do we have to be able to invalidate them if new rules are added via out-of-band means? | ||
TimToady | or build a trie | ||
pmichaud | I guess each grammar could keep track of them | ||
TimToady | I presume so, including adding entries to grammatical categories | ||
pmichaud | i.e., we can ask a grammar "what are the initial constant strings for rule xyz?" | 20:53 | |
TimToady | but maybe the update can be done incrementally. | ||
pmichaud | which it then computes if it doesn't know already | ||
TimToady | or used to know and forgot... | ||
pmichaud | and it saves information as it goes so that the next time it's asked it doesn't have to recompute the whole thing | ||
TimToady | crudely, generation++ would work | 20:54 | |
but most changes via declaration are incremental | |||
postfix:<!> and such | |||
so could probably propagate the fact that you need to do an insertion on your table or trie | |||
without rebuilding the whole thing | 20:55 | ||
pmichaud | do we need to specify the optimization mechanism in S05, or can we leave it up to the implementations to decide the best way to determine "longest initial constant match"? | ||
TimToady | I was wanting to leave that as open as possible | ||
20:55
cdpruden joined
|
|||
TimToady | for some datasets it's probably fastest to falsify on character N rather than character 1 | 20:56 | |
pmichaud | okay, I think I've got it for now | ||
luqui | are the semantics of /<a> | <b>/ to match whichever of /<a>/ and /<b>/ is longer, or just to go to the one with the longest initial matching constant string? | ||
TimToady | oh, let's see, I'll also need to mumble something about longest tokens requiring \b after identifiers by default... | 20:57 | |
luqui | and continue from there... | ||
pmichaud | as I read S05, try the one with the longest initial matching constant string first | ||
TimToady | that's correct | ||
longest token :: rest of rule | |||
pmichaud | if it fails, backtrack to try another matching alternative according to the same criteria | ||
TimToady | and :: in fact specifically terminates "token" | 20:58 | |
luqui | so it's concievable that /<a> | <b>/ could match <a> even if <b> ended up being longer... | ||
TimToady | so does key/value boundary in hash match | ||
pmichaud | does any quantifier terminate "token"? | ||
TimToady | believe so | ||
pmichaud | that's what I was working from | ||
TimToady | (to both of you) | ||
luqui | that seems incredibly brittle | 20:59 | |
pmichaud | luqui: I think if it's brittle then use || instead | ||
luqui | i.e. optimizations have the potential to change semantics | ||
that's a cop-out answer... | |||
pmichaud | agreed :-) | ||
luqui | why should the semantically unstable one be the shorter one? | ||
(or more accurately, why are we including a semantically unstable operator in the language?) | 21:00 | ||
TimToady | I don't see how it's unstable. It's no different than any other lexer/parser works... | ||
every lexer commits to the current token regardless of which production turns out longer | 21:01 | ||
luqui | if you insert "predictive, top-down" in there, you might be right | ||
oh, so you're looking at this from a tokenizer standpoint | |||
but the definition of what a token is is ad-hoc | 21:02 | ||
TimToady | it's defined by the rules you call. | ||
luqui | whereas when you're using flex/bison, you have defined exactly what your tokens are | ||
and flex always picks the longest one | |||
TimToady | for your current lexer state | ||
and lexer state is usually a proxy for a parser state. | 21:03 | ||
luqui | but where is the line between tokens and productions? | ||
TimToady | we're just attaching it directly to your parser state | ||
luqui | (is it the "token" keyword?) | ||
TimToady | no, token is whatever is constant on the front up to :: | 21:04 | |
pmichaud | I think the line between tokens/productions is the set of initial constant strings :-) | ||
TimToady | or something non-constant like \b \s* etc | ||
pmichaud | in something like / a+ / -- would the initial constant string be 'a'? | ||
luqui | but that prohibits refactoring constants into data structures... | 21:05 | |
21:05
Aankhen`` joined
|
|||
TimToady | %hash keys are considered constants too | 21:05 | |
pmichaud: can argue that both ways | |||
pmichaud | TimToady: so can I , which is why I asked :-) | ||
TimToady | I'm inclined to say not, but don't have a really good reason | 21:06 | |
luqui | TimToady, didn't you just lose your optimizations by saying that? | ||
(%hash keys are considered constants | |||
) | |||
TimToady | not if you know whether the hash has changed or not. | ||
it's just another way for linkage to change | |||
p5 would just have done generation++ | 21:07 | ||
and recalculated the world | |||
luqui | so %hash keys don't count as constants if they are passed as parameters to a rule? | ||
TimToady | and been fast usually | ||
we might need to be careful about terminators | |||
pmichaud | I think I prefer that / a+ / have '' as an initial constant string, if only to be able to deal with things like / a**{$m..$n} / later | 21:08 | |
TimToady | maybe hardwire ) ] } as terminators and don't revise hash if the parameter is one of those terminators | 21:09 | |
luqui doesn't follow | 21:10 | ||
pmichaud neither | |||
TimToady | most parameters turn out to be terminators, I suspect | ||
whichever way a+ goes, we have a way to write it the other way | |||
:: a+ / would force to "" | |||
s/^/\// | 21:11 | ||
pmichaud | yes | ||
TimToady | and / a a* / of course | ||
though that violates DRY | |||
which tends to argue for "a" by default | |||
just for optimizing purposes mainly | |||
less for tokenizing | |||
pmichaud | well, if it changes semantics, is it really just optimization? | 21:12 | |
TimToady | see tailcall optimization... | ||
luqui | pmichaud++ # my sentiment exactly | ||
how does tailcall change semantics? | |||
TimToady | guarantees you don't blow your stack with recursive solutoins | 21:13 | |
luqui | given enough ram, there is no change in semantics | ||
i.e. on a turing machine, there is no difference | |||
pmichaud | in this case, the chose of returning 'a' versus '' could be very different | ||
s/chose/choice/ | |||
unfortunately, I have to run off and make it to the post office to meet a mailing deadline | 21:15 | ||
TimToady | k | ||
pmichaud | if I come up with any other questions, I'll ping or write to the ml | ||
(or tomorrow's call) | |||
TimToady | k | ||
pmichaud | thanks a bunch for the quick answers -- this is fun stuff to think about :-) | 21:16 | |
luqui | so, TimToady, are you trying to emulate a predictive parser (like parsec) with these changes? | ||
pmichaud | luqui: this question came up on #parrot a few days ago -- someone was using an alternation of / .pcc_sub | .pcc_sub_begin / and was curious as to why .pcc_sub_begin never matched | 21:17 | |
it becomes odder when one writes token sub { .pcc_sub | .pcc_sub_begin } | |||
TimToady | um, we've been predictive ever since we introduced :ratchet | 21:18 | |
luqui | note that both of those have an initial constant string of "" | ||
pmichaud | sorry, backwack the dots | ||
luqui | but if the dots weren't backwhacked... | ||
then the problem remains | |||
pmichaud | it does also bring about the question of what to do with, say { $foo } :-) | 21:19 | |
s/say// # darn puns | |||
I better get to the P.O. if I want to avoid a legal hassle -- bbiaw | 21:20 | ||
luqui | I just don't see the win... it seems like if I use | in a grammar I need to be maticulously knowledgeable about the exact details of how my rules are written to understand the behavior | ||
and it's pretty easy to do a similar optimization on || | 21:21 | ||
just look at constant strings on the left, and if one matches, jump there and try it | |||
pmichaud | luqui: that was true before. What's different now is that I need to know the details of my subrules to understand the behavior | ||
luqui | if not, try the right | ||
luqui meant subrules | |||
TimToady | pmichaud: go away!!! :) | ||
luqui dittos | |||
:- | 21:22 | ||
:-) | |||
pmichaud | I can't! I'm having too much fun! Taxes are not generally -Ofun! | ||
(gone, for real this time) | |||
ingy | /kick pmichaud | ||
TimToady | I wonder if commutative should be specified with <=> in place of comma... | 21:25 | |
then you can have your first 2 args commutative without the 3rd... | |||
luqui | what if you want your 1st and 3rd commutative without the second? | 21:26 | |
luqui thinks "is commutative" is good enough | |||
no more syntax for minor details please | 21:27 | ||
use words for little things, so they're easy to look up, and presumably easy to read without having to look up | 21:28 | ||
(<=> isn't obvious to me) | |||
TimToady | how 'bout multiple signatures for a single body? | ||
luqui woots | |||
*that* is a pretty good idea I think | 21:29 | ||
TimToady | every now and then... | ||
luqui | could take a bit of pain out of multi disambiguation | 21:30 | |
you still have a combinatorical explosion to deal with now and then... | |||
TimToady | but at least you don't have all these {...} scattered all over | 21:31 | |
well, need to glare at that one for a while... | |||
luqui | (Foo $a, Bar $b | Bar $b, Foo $a) # match the longest initial object... | 21:32 | |
21:32
jferrero joined
|
|||
TimToady | hmm, current subsig syntax already allows it, almost, except it would bind both subsigs to the first arg only... | 21:33 | |
ah, no, it would be anded not ored | 21:34 | ||
so subsigs wouldn't work in any case | 21:35 | ||
I think people would read | as binding tighter than , | |||
luqui | especially since it does a lot of the time (Foo | Bar $x) | ||
but || is available... (might be too much punning) | 21:36 | ||
TimToady | I was just thinking (Foo $a, Bar $b) (Bar $b, Foo $a) | ||
theorbtwo | (Foo $a, Bar $b) | (Bar $b, Foo $a) might be clearer. | ||
TimToady | or (Foo $a, Bar $b)|(Bar $b, Foo $a) maybe | 21:37 | |
theorbtwo grins. | |||
TimToady | and rightfully so. | ||
TimToady wonders if all the alternatives must declare the same parameters or fail compilation... | 21:39 | ||
or if unbound ones just become undef | 21:40 | ||
luqui | I like failing as long as it's easy to specify defaulting to undef | ||
but it's not the same as $param | |||
TimToady | former behavior is more conservative, and we could relax to latter later | ||
luqui | er | ||
$param? = undef | |||
(i.e. $param? ;-) | |||
TimToady | I like the double check, since it would be easy to mix up $a and $b | 21:41 | |
though if you did get them backwards, it might have some spectacularly hard to diagnose failure modes | |||
assuming the type inferencer doesn't complain loudly | 21:42 | ||
which it can certainly do if it decides $a.WHAT === None | 21:45 | ||
but as soon as people start throwing Any in there we have to pretty much trust them to mean what they said. | 21:46 | ||
21:49
kanru_ joined
|
|||
luqui | but this is mainly for mmd, right? | 21:50 | |
so Any will not be very likely | |||
TimToady | ya | ||
gives you an asymmetric default case | |||
luqui | because it has no information | ||
TimToady | Num/Any | ||
vs Num/Num | |||
luqui | elaborate | ||
TimToady | it would dispatch a Num/NotQuiteaNum to Num/Any, presumably | 21:51 | |
if your mmd coerced its right arg to Num, for instance. | 21:52 | ||
luqui | oh, I see the problem.. if you had (Num $a, Any $b) | (Any $a, Num $b) | ||
TimToady | /mmd/mm/ | ||
and forget to swap $a and $b | |||
luqui | Num|Any = Any, so both $a and $b would get typed as Any | ||
TimToady | and how would you detect the error? | 21:53 | |
well, you'd have the same problem if you cut-n-paste the body... | |||
luqui | aye | 21:54 | |
TimToady reminds himself not to cut-n-paste any bodies in public) | |||
one thing the design of Ada taught me is that eventually you just give up and say "that's just erroneous, and we can't do diddly about it." | 21:55 | ||
luqui | I mean, if you have strong type inference on (because weak inference isn't going to catch anything; it's just going to assume you're right), then Any will die on many things, because you can't do anything to it | ||
TimToady | saved by the pragma. :) | ||
no stupid; | |||
luqui | haha | ||
luqui considers making it so at least the types of the same parameter in different signatures have to match | 21:56 | ||
but that seems to take away some power | |||
TimToady | hmm leave out the params on 2nd and following, and have them autoassociate with the type? | 21:57 | |
luqui | uh no | 21:58 | |
a little too dwimmy for my taste | |||
TimToady | prolly | ||
luqui | (Any, Num) | (Num, Any) ($a, $b) | ||
oh wait... that's the erroneous case! | 21:59 | ||
(Any $a, Num $b) | ViceVersa. (I guess that's spelled "is commutative") | |||
TimToady | you'd probably want (Any, Num) | (Num, Any) -> Num $a, Any $b {...} | ||
luqui | yikes | 22:00 | |
theorbtwo | Why not just spell that (Any $a, Num $b) | ($b, $a). | ||
Allos explicit types on the second, but do not require it. | |||
luqui | that's interesting | ||
TimToady | Don't see that it's much different than (Any $a, Num $b) | (Num, Any) | 22:01 | |
though I guess that flips the order too | 22:02 | ||
theorbtwo | For one thing, what does (Num $a, Num $b, Str $c) | (Num, Str, Num) mean? | 22:03 | |
TimToady | also ($b, $a) is a valid sig in it's own right | ||
which always means (Any $b, Any $a) | |||
so you can't also make it default, I think | 22:04 | ||
luqui | ... true ... | ||
TimToady | probably best to stay explicit for now | ||
and make the IDE flip entire paramlets for you... :) | 22:05 | ||
presumably when you hit the "commute" button. | |||
sec & | 22:06 | ||
22:06
ruoso joined
|
|||
TimToady | (Num $a, Any $b) || (Num $a, Num $b) # desugared ; | 22:09 | |
luqui | Num, Num? | 22:14 | |
TimToady | desugared Num; Num | 22:16 | |
luqui | ? | ||
oh | |||
TimToady | note || instead of | | ||
luqui | semicolon | ||
TimToady | (Any $a, Num $b) || (Num $a, Num $b) # backwards semicolon | 22:18 | |
I'm probably all dingled in the head though | 22:19 | ||
ingy | /topic <TimToady> I'm probably all dingled in the head though | 22:21 | |
22:25
dduncan joined
22:32
gnuvince joined
22:36
Limbic_Region joined,
weinig|bbl is now known as weinig
22:40
ludan joined
22:43
trym_ joined,
[particle] joined
|
|||
TimToady | n | 22:53 | |
not to mention y | |||
23:07
ludan joined
|
|||
luqui is beginning to agree with TimToady's assessment about his head :-) | 23:12 | ||
TimToady | I prefer it when you're disagreeable. :) | 23:15 | |
23:15
Psyche^ joined
23:24
xinming joined
23:29
Psyche^ is now known as Patterner
23:46
neonse left,
ludan joined
23:50
Ziggy6 joined
|