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:42 aindilis joined
meppl good night 00:44
00:45 bsb joined 01:04 aindilis joined 01:12 stevan__ joined 01:16 araujo joined 02:05 justatheory joined 02:13 lyokato_ joined 02:43 agentzh left 03:53 felipe joined 04:03 Ingmar left 04:44 stevan_ joined 05:53 baest joined 05:54 Maddingue joined 05:55 pjcj joined, BinGOs joined 05:56 Lunchy joined 06:01 yahooooo joined 06:14 zamolxes joined 06:16 devogon joined 06:31 kanru joined 06:42 elmex joined 07:00 IllvilJa joined 07:24 araujo joined 09:07 meppl joined, nothingmuch joined 09:16 masak joined 09:39 meppl joined 09:56 agentzh joined 10:15 zamolxes joined 10:44 ruoso joined 10:49 chris2 joined 11:23 LazyJim joined 12:20 FurnaceBoy joined 12:23 masak joined 12:30 devogon joined 13:16 Jedai joined 13:20 Aankhen`` joined 13:52 alester joined 13:55 acmoore joined 14:16 hcchien joined 14:41 kanru joined 14:42 rdice joined, revdiablo joined 14:51 LazyJim joined 15:47 TJCRI joined, lidden joined 15:56 bsb joined
moritz_ tries to resurrect exp_evalbot 16:37
16:42 exp_evalbot joined
moritz_ pugs: say "hi" 16:48
exp_evalbot OUTPUT[hi␤]
moritz_ in case anybody wonders... the server on which exp_evalbot runs has ghc 6.6.1 installed (debian etch + a few backports), so pugs will stop dead at its current revision 16:49
17:10 eternaleye_ joined 17:11 tobeya joined 17:22 pjcj joined, meppl joined 17:29 TJCRI left 17:32 Jamtech joined 17:35 eternaleye joined 17:36 b_jonas joined 17:44 justatheory joined 17:53 Jamtech joined 18:08 mncharity joined
mncharity TimToady: in STD.pm, 'token infix:sym<=>' is the only 'token infix:sym' without a return type? 18:10
18:22 pmurias joined, rindolf joined
pmurias what does the return type for tokens in STD mean? 18:23
mncharity: i changed Emit::AstYaml to return yaml instead of printing it 18:24
18:25 Tene left 18:27 eternaleye_ joined 18:30 Psyche^ joined
TimToady mncharity: yes, because assignment may be coerced to either item assignment or list assignment at "make" time. 18:31
pmurias: when viewed as a method, any regex is really returning a match cursor regardless of what the user thinks is being returned 18:33
so the return type on a regex is really the coercion of the "make" object
which ends up in the scalar slot of the match object (or the match object implicitly contained within a cursor) 18:35
so it's really the coercion of that Match object, whether or not there was a make() 18:36
(probably) 18:37
it's a little bit strange the way currently envisioned 18:38
it makes more sense to coerce $/ when there's no make, but when there's a make it might make more sense to coerce $$/
factoring into this is that under various semantics of :keepall, we want to hold onto the Match as well as the scalar object, so you can't just throw away the Match when you do a make necessarily 18:40
pmurias i read more of STD and understood what are the types for 18:43
TimToady when I say "coerce" I'm really meaning something more like mixins 18:46
that is, not so much to change the type, but to add in info such as prec and assoc... 18:47
except we're kinda adding that into the Match object, not the make object, so there's something screwy somewhere in my thinking (not unusual) 18:48
I suppose I should call it the result object to be consistent 18:50
anyway, the match object and the result object keep fighting with each other
mncharity pmurias: i saw :) does it still work on unicode << ? 18:52
18:57 barney joined
pmurias mncharity: don't know 18:59
the whole deamon compiling is a bit broken 19:00
pugs_svnbot r20128 | putter++ | src/perl6/STD.pm: Added a comment explaining infix:sym<=>'s singular lack of return type. Tweaked the code formatting of 'method panic', to make STD_extract happy.
diff: dev.pugscode.org/changeset/20128
lambdabot Title: Changeset 20128 - Pugs - Trac
pmurias and script/kp6 needs a refactor
mncharity TimToady: in STD.pm, 'regex prefix_circumfix_meta_operator:reduce' is the only categoryfoo:bar instance which is a regex. could it be a token or rule instead? 19:03
TimToady: Q2... feel free to suggest a different communication strategy - the current one is "/me mentions oddities as they go by":), rather than distinguishing "blockers - or things which will cost me time" from "hmm, that's odd". 19:05
Q2 - there are only a few things which are "regex", so going down the egrep '^regex' STD.pm list, 19:06
could nofat be a token instead? it's just two <before>s. 19:07
regex fulltypename also seems like it could be a token? 19:08
re "in STD.pm, 'regex prefix_circumfix_meta_operator:reduce' is the only categoryfoo:bar instance which is a regex. could it be a token or rule instead?", never mind. already asked, answered, and was documented in a comment even before that. sorry. 19:09
'regex stdstopper' however isn't marked as backtracking. 19:10
So 3 "why is this a regex?" oddities (outside of the quoting stuff): nofat fulltypename stdstopper 19:11
pugs_svnbot r20129 | putter++ | misc/winter_jig/STD/STD_extract: Sync'ed with current STD.pm. Added more bitrot detection to make it easier next time. 19:24
diff: dev.pugscode.org/changeset/20129
lambdabot Title: Changeset 20129 - Pugs - Trac
mncharity STD.pm's 'token expect_infix' needs #= tags. 19:25
oh, nm. "todo ... finish out all the {*} #= hookage" 19:26
19:27 elmex joined 19:33 silug joined
TimToady mncharity: it's possible that prefix_circumfix_meta_operator:reduce won't have to backtrack if we can shove all possible reduce combinations into LTM, but it might get too combinatorial, esp if the user adds more infix metaoperators that can be inside/outside other metaops 19:39
I'll try to look at the others when I get a chance, but have to eat and $work
19:42 rindolf joined 19:43 Auzon joined 19:45 elmex joined
TimToady I mean, being the hospital was a good excuse to take last week off, but not this week...I hope... :) 19:50
s/the/in the/ 19:51
kolibrie this is post-recovery week
TimToady I don't think any number of transfusions are going to get me to type straight though...
19:56 dduncan joined, dduncan left
b_jonas wow 19:57
is prefix_circumfix_meta_operator the longest keyword ever?
-- getprotobynumber 20:02
it's definitely longer than that
mncharity re good excuse, :) 20:07
re longest, :) 20:08
re 'get a chance', np. :)
re :), :) 20:09
(that last for smilely, the new statement terminator) 20:10
TimToady: the yaml dump which gimme5 drops in DATA, any guidance on whether it is complete, is correct? 20:13
mncharity considers making an oo (and thus yaml) representation of STD, to do more analysis. Eg, a big table of ruls vs do they have code? use env vars (and which)? participate in OOP? etc. 20:14
20:16 jferrero joined
b_jonas S03 says "postcircumfix" at some places, so the right terminology might be precircumfix_meta_operator 20:18
which is shorter
though it also says prefix_circumfix_meta_operator explicitly
(when it comes to meta-operators syntax, I like J's grammar. It's simple, but enough for almost all practical purposes.) 20:20
TimToady the long ones are long on purpose 20:21
the longer they are, the less you should be messin' with 'em
b_jonas (though as very few languages have meta-operators syntax, I suppose I could say perl6 has stolen the idea from APL or a descendant)
TimToady hmm, I'd say it's independent discovery 20:22
b_jonas really?
I mean, even the most popular ones are the same
20:23 BinGOs joined
b_jonas the first meta-operators apl had were / (reduce), \ (scan), and . (matrix product) 20:23
iirc
whereas perl6 has reduce, scan, and what else? 20:24
pmurias hyper
TimToady I never really studied APL; closest I got to it was watching my brother-in-law implement a PDP-11 interpreter for it
and assign ops reclassified to metaop
likewise negation 20:25
$a !eq $b
b_jonas btw, I mean stealing in the good sense: www.undefined.net/1/0/
lambdabot Title: 1/0 Archives
TimToady understand that
b_jonas ah yeah, negation
TimToady but mostly I was just generalizing from op= in my head
and initially it was just hyperops 20:26
reduce came later
b_jonas apart from perl6, I've only seen that as a meta-op in Arc
ah yeah, the map operator 20:27
that's in Apl too of course
I knew I forgot something
TimToady mostly my exposure to APL was way back in the MEGO days, so I don't recall every learning that there were metaops
b_jonas though old Apl, Apl with boxes, Apl2/J, and Perl6 does the map thing in different ways
MEGO?
TimToady My Eyes Glaze Over
I was mostly just a BASIC programmer back then 20:28
more than 30 years ago...
b_jonas if you discovered them independently, that's nice though 20:29
TimToady most of my original functional notions came from Lisp, at least on the conscious level
b_jonas because I really admire how Ken Iverson choose the right primitives
and how he could remove the primitives that turned out to be unnecessary 20:30
(a very old paper lists some functions that were removed) 20:31
(that was before Apl got implemented on a computer)
TimToady well, hey, everyone refactors occasionally...
b_jonas (link: www.jsoftware.com/jwiki/Doc/A_Source_Book_in_APL ) 20:32
lambdabot Title: Doc/A Source Book in APL - J Wiki
TimToady the problem with a mathematician refactoring is that they tend to factor out the humanistic shortcuts, which renders a language usable only by geniuses 20:33
b_jonas I'd like a language with Apl's primitives BUT real lambdas 20:34
K has gone too far from Apl in that respect
let me say, I'd like one with Apl2/J's primitives and syntax rules BUT real lambdas
TimToady mncharity: it's a complete parse of the tokens/rules for purposes of LTM generation, but the p6 code ends up translated outside of DATA 20:35
b_jonas (though the bigger problem with K is the lack of documentation)
TimToady I prefer a language with a few more precedence levels :) 20:36
pmurias TimToady: you wouldn't like mp6 20:37
;)
TimToady anyway, speaking of precedence, I really need to commute to $dayjob
20:43 BinGOs joined 20:46 meppl joined
mncharity STD: 656 ruls, routines, and classes. sigh. 20:47
b_jonas TimToady: if in perl6 you can assign precedence to operators returned by hyper-operators, 20:48
then you could in theory make a langauge with apl's primitives, meta-operators, but percedence-ful syntax.
whether that'd be better or worse than apl is not trivial.
mncharity /me wishes for a all_the_information_in_STD_made_easily_accessible.pm . 20:49
20:51 Psyche^ joined 20:56 Psyche^_ joined
PerlJam mncharity: Just write something that can parse STD.pm and the introspection bits and there you go! 20:56
mncharity: and by my estimation, PGE and friends get you more than half way there. 20:57
b_jonas so perl6 has an outer product metaoperator by default (S03) but not an inner/matrix product metaoperator
20:58 Chillance joined
b_jonas and it has a less potent "hyperoperator" 20:58
than apl
so this is the difference
does perl6 have "boxes" so you can use the hyper-operator in a more powerful way? 21:00
pmurias b_jonas: what are "boxes" 21:01
?
b_jonas pmurias: in itself, a box is just a simple container type that holds a single value, with the only interesting operations being boxing and unboxing 21:02
but where it gets interesting is that you can have the map/hyper operator behave specially on it 21:03
in that it unboxes elements but doesn't propagate in the boxes
the perl6 hyper-operator acts recursively on multi-dimensional arrays
but it could stop at the first level of boxes
this way, you can do ranked operations the apl way 21:04
I'd give an example but that would be flooding so I'll try to paste one somewhere
21:05 dduncan joined
pmurias mncharity: i wander if it wouldn't be wiser if one intended for a perl6 subset eqivalent sematicly to perl5 instead of trying to bootstrap kp6 just to revive mp6 21:06
mncharity re 'alf way there', STD_extract is already sort of half way there. and cheat/gimme5 a different half+. need to be combined and expanded. not so much a technical challenge, as... pause 21:07
pmurias s/wander/wonder/ 21:08
mncharity pmurias: good thought. my working hypothesis is
hmm, the challenge is to attract developers. else we just end up with yet another dead p6 implementation. 21:09
21:09 dduncan left
mncharity yadp6i 21:09
one way to do that would be to "it's the full, real, spec grammar". "any spec p6 which doesn't parse, is a mistake, easily fixed working in {p5,p6}". 21:11
and work from there towards a sane ast's, and ir's.
a STD-based parser would thus provide a "place to stand". one point of non-"assortedly broken bootstrap kludgery". 21:13
21:14 qmole joined
pmurias is just "it yet another silly subset" aspect scarying people of p6 implementations? 21:14
mncharity I'm a great believer in bootstrap kludgery. :) as a techincal approach. but I think we have a social, not technical problem at the moment. too many years of "it sort <break - yes, what you said>" seem to have killed developer interest. 21:16
pmurias or are implementations issues such as being forced to work in horid languages such as mp6 or pir more important
mncharity that's my impression. could be wrong. interested what you think. re 'or', hmm... 21:17
both?
pmurias what do you mean by "it sort <break - yes, what you said>"? 21:19
mncharity I was trying to figure out how to say "it yet another silly subset", when you did. :)
s/did/said it, so I could stop/ 21:20
pmurias ;) 21:21
mncharity horrid has two impacts. it raises the effort and motivation required. and it reduces clarity. "clarity" being the obviousness of "this isn't just another dead-end subset". 21:22
A pugs-level capability implementation written in p5/Moose might be viable. But kp6-level is apparently not. I had hoped a something in between, with good usablity, might be viable. But got stuck for lack of a usable parser. If one needs to 21:26
fight the parser battle anyway, the best chance of finding anyone to work with, and of the result being used, and of an implementation based on it attracting developers, is something STD-based. Even if parts of it are still a work in progress. 21:28
pmurias getting STD to work is a bit of a bottleneck 21:30
mncharity true. but mostly in the EXPR handling. 21:31
my hope is/was having all_the_information_in_STD_made_easily_accessible.pm would let you easily do things like, "ok, here are the n rules into which EXPR handling leaks. let's try making progress by avoiding the EXPR wall. rip out the cruft, drop in a simple OPP, move on". 21:34
s/easily do/easily try/
b_jonas hpaste.org/6452 21:35
pmurias: hpaste.org/6452 explains boxing combined with apl's each (diaresis) operator
pmurias you mean being able to just take a few rules out of STD conveniently
21:37 larsen joined
pmurias i see, having all the interactions between rules easily visible 21:39
mncharity yes. for example. with ~700 components, and implicit relationships (eg, using environment variables), and "it really wouldn't work as written" (STD_red got hit here), and it's hard to tell the consequences of changes (eg, implementing | as ||, or punting non-local longest-DFA-ness, or replacing that with lookahead, or...)...
pmurias EXPR dosn't seem especialy simple 21:40
mncharity it's just not a managable exercise with better infrastructure.
pmurias s/simple/complex/
mncharity which to get back to PerlJam's observation, isn't particularly technically difficult to create (re all_the_information_in_STD_made_easily_accessible.pm), but... I'm getting burned out on "here I am restarting work on something I was doing n months/years ago, no one has 21:42
touched it in the interrum, and no one is interested in working on it with me, so it would be yet another solo p6 slog".
b_jonas dunno if that description make sense
also dunno if it would make sense in p6 21:43
mncharity re 'EXPR dosn't seem especialy complex', the difficulty is more that it's no local. leaking into things like 21:44
token noun's <variable> line. 21:45
| <variable> { $<sigil> = $<variable><sigil> }
and all the rules (how many? which? dunno) which are doing $<prec> passing. 21:46
STD_red was sort of based on "I don't *have* to know 'how many?', 'which?', 'are some missing?', 'what would need to be changed to modify it?'". "I just transliterate what's there in STD.pm, and if any of it doesn't work, that's someone else's task to fix, and it is likely to happen fairly quickly". 21:49
those assumptions/speculations turned out not to be true, so STD_red got rather less interesting, and STD analysis tools again rather more so. 21:51
re 'EXPR dosn't seem especialy complex', maybe not. looks like there are only 8-ish things with <prec>. 21:55
some things like token infix:sym<=> () { <sym> { self.<sigil> eq '$'?? make Item_assignment($/) !! make List_assignment($/); } {*} } which need to be massaged into something else. 21:56
./STD5_run EXPR -e '3 = 4' isn't working at the moment. '3 - 4' does. 22:00
s/at the moment/yet/
basically there's a bunch of details, and a lot of clutter obscuring them.
and that's _before_ starting to debug - in just writing the code intended to run. 22:01
pmurias maybe OPP should abstracted in a module instead of being scattered around 22:03
mncharity b_jonas: re boxing, it's on my infinite todo list for p6, along with a full apl implementation. but... not any time soon. 22:04
b_jonas mncharity: by "full apl implementation" do you mean completely unrelated to perl6?
mncharity though sooner than you might think, because one way to demonstrate "we're finally real now" with clarity is to be running, and fully passing, other languages' test suites. and past work suggests a well spec'ed and test suited language can be _very_ easy to implement in p6. 22:05
b_jonas I want to write a J implementation but that's really long term so might not happen 22:06
mncharity re unrelated, well, sort of. p6 can do { use Apl; ...<this is apl code>... }. so that, rather than language blending, which is a much harder exercise.
22:07 Limbic_Region joined
b_jonas yeah 22:07
except for the closing brace I guess 22:08
mncharity sub sortit (@X) { use Apl; X[↑X+.≠' ';] }
b_jonas what I meant is, it's not like adding apl operators and higher-order operators to the p6 grammar with a module
mncharity right. doing that is a harder, much more artistic, language design exercise. 22:09
b_jonas yeah
mncharity embedding is just legwork.
b_jonas let me try to understand that sub
mncharity I just snarfed it from en.wikipedia.org/wiki/APL_(programming_language) 22:10
lambdabot Title: APL (programming language - Wikipedia, the free encyclopedia
b_jonas X [ (first X) (+ . notequal) ' ' ; ]
mncharity spoiler warning 22:11
the wp page says what it does
pmurias mncharity: would STD.pm look much diffrently if a full p6 implementation was avalible? 22:12
mncharity hmm, interesting question.
b_jonas doesn't seem to make sense to me
probably because I don't really understand apl 22:13
I'll check the page
mncharity " sorts a word list stored in matrix X according to word length:"
b_jonas I think that's wrong 22:14
the up arrow should be the rank up symbol
triangle with vertical bar
otherwise how would it sort?
and then I parenthisized the expression wrong too 22:15
either I'm misunderstanding how apl precedence used to work, or that's wrong too 22:16
let me check
I have an apl somewhere here that's working
I think it's supposed to mean this:
hpaste.org/6456 22:17
mncharity re 'look different', one issue would be the "how is OPP information being passed around via Match objects", which was discussed earlier today as a uncertainty. ...
hmm, left room. ...
well, aside from details, a big picture issue is that with a real full p6 impl, parts of STD.pm might go away, becoming artifacts of the macro or sub declarations they serve. eg, a real prelude might(?) have a macro statement_control:if is parsed as ... {...}. which generates the current statement_control:if token. 22:20
b_jonas I was wrong in the precedence 22:23
then I'll have to look up how precedence worked in apl
mncharity my impression the current areas of uncertainty are () passing info via Match objects, () how to do mostly-non-backtracking DFA-ish parsing, () or if you don't, whether and how you lose, and how that might be worked around, () ...? 22:24
() actually testing and debugging it ("if it isn't tested, it doesn't work", so each time a new section gets tested, issues turn up. 22:25
for difficulty rather than uncertainty, there's also () dealing with all the many bits of inline code, including translating them as to another language if necessary, () attaching all the rule labels named in #='s. 22:28
b_jonas but I'm quite sure the up arrow is wrong, it should be delta stile
mncharity /me wonders if someone is providing a website on which one can easily run small apl programs. 22:29
b_jonas mncharity: there's one for J 22:30
I can find its link if you need it
(but it's easier to use the irc bots evaluating J)
mncharity not needed
apl irc bots? nifty.:)
b_jonas mncharity: I don't know any for apl, but there might exist one 22:32
though most apl implementations being non-free might hinder that
but there's a bot running mathematica too, so who knows
there are bots for J 22:33
however, there are shareware J interpreters you can run locally
mncharity pmurias: so, if you would be interested in working on a all_the_information_in_STD_made_easily_accessible.pm , or have any questions, just let me know.
b_jonas once you write the apl thing for perl6, we'll have it in the perl6 evalbot easily 22:34
mncharity grabbing bits from svn.pugscode.org/pugs/misc/winter_j...TD_extract (careful parse of STD), plus svn.pugscode.org/pugs/src/perl6/cheat and svn.pugscode.org/pugs/src/perl6/gimme5 (for the regexp pattern parse tree). plus some oo classes to represent the assorted rules, and answer questions about them. 22:37
are you part of a tree? gimme your tree to a p5 regexp. list your subrules. do you have any code? do any of your subrules take arguments? do you use any of the environment variables? which? etc. 22:39
b_jonas though for small programs, we could try to write a quick-and-dirty mini apl-interpreter 22:40
mncharity basically, cheat+gimme5 should be able to be refactored into part which understands what STD.pm says, and a separate part which emits a parser representing certain policy choices (like target language, how backtracking and lookahead are handled, how #= nodes are labeled, etc). 22:41
But, I need to find someone to work with in order to pursue it. Alternately, if someone would like to work together on something else plausible, that could be good too. 22:44
TimToady I think retargetability is outside the scope of a gimme5 approach. whole point is to scrap gimme5 as soon as STD can parse itself.
Limbic_Region feeling any better TimToady? 22:45
TimToady it's amazing how much better one feels when one isn't down a half a gallon's worth of blood 22:46
mncharity "a gimme5 approach" meaning a code s///ing approach?
Limbic_Region won't asked where they stuck the dip stick to take the reading
TimToady I can walk uphill again without going anaerobic...
Limbic_Region that might have been funnier if I hadn't made the grammatical typo 22:47
TimToady mncharity: yes, it's not really a true parser except for the p6 regexen
well, I've already had a dipstick from the top end; get to wait a couple weeks for the other end...
basically, they don't know why yet, though the blood tests indicate leakage 22:48
as opposed to excessive destruction or inadequate creation
CT scan negative, upper endo negative
Limbic_Region yeah, I read that in the p6 irc logs
TimToady lungs and heart fine
can still be 5 or 6 common things 22:49
mncharity: but yet, for p5 it's just s///ing the heck out of it rather than attempting a parse/emit, since p5 is a closely enough related language to get away with it (for this purpose only) 22:51
*yes
mncharity cheat/gimme5 seems a couple of distinct bits. the file-specific "parsing", the regex parsing, the getting access to the information therein which you care about, and the emitting parser code.
if gimme5 could parse STD, that would take care of the parse steps, but
b_jonas wait
apl has the same precedence rule as J? 22:52
I always thought it had a different one
TimToady if gimme5 could parse STD, I'd pretty much have a Perl 6 parser :)
mncharity if you needed something else to parse STD as well, you would still need the "get access to the info", and the "emit something else" bits.
TimToady but I'd rather think of the output of gimme5 as a real p6 parser, not gimme5 :)
b_jonas I'll look up if it was always like that or changed in apl2 22:54
mncharity at one point gimme5 looked like a DFA research project. is that still true, or has confidence in the approach increased?
TimToady that part is very nearly done, I think, apart from maybe refactoring the actual interfaces between rules as we go along
the main blocker on LTM is just that I haven't propagated a* b patterns right yet 22:55
b_jonas yep, this old document says it was always like in J
TimToady so that I know where a*b can mean ab
b_jonas I don't know why I imagined otherwise
TimToady currently a*b doesn't know how to propagate the b prefixes upward 22:56
b_jonas useful to know
TimToady the Match/Result confusion mentioned earlier is the other main blocker
mncharity so gimme5 might become a real p6 parser, rsn, for some value of rsn? 22:57
TimToady I think so
well, the output of gimme5 rather :)
gimme5 will always just be chewing gum and bailing wire
as far as the actual design issues with STD 22:58
the string sublanguage stuff is likely to undergo an amount of refactoring
more generally, the relationships of various sibling sublanguages has to be tracked correctly 22:59
mncharity relationships?
TimToady for instance, a regex containing {...} should use the same p6 variant that was outside the regex
mncharity ah 23:00
TimToady and that might itself be a derived language, just as regex is
mncharity err, p6 variant... of quoting?
TimToady some of this is solved with virtual classes
mncharity ah, ok
TimToady quoting is just one way of mixing up various derived or related languages
b_jonas can't some of that be solved by the string parser handling back the work to the parent parser when it sees a brace? 23:01
I think that's how it works in ruby
TimToady but again, if you interpolate an expression, say, the langauge inside the expr has to be the same as outside the quote
it's not exactly just "handing back" 23:02
the inner expr just starts out in the outer language, but could itself mutate within its lexical scope
that must automatically restore at the outer scope
b_jonas yeah, it's simpler in ruby where the only such case is catenating something to a string 23:03
TimToady it's not that the inner expr is passed to the outer parser
it's that the inner expr starts parsing with the same parser, but might diverge
mncharity why isn't the language inside the expr just whatever is in our Perl $*PARSER or somesuch?
TimToady this goes for an lexical subscope, not just interpolations or eval
b_jonas so it's easy to just treat '"foo @{[' as '"foo " . ' with the extra thing that if the normal parser meets the closing brace, it hands the work back to the string parser 23:04
mncharity my Perl $*PARSER then?
b_jonas hmm
TimToady something like that
mncharity but before my "relationships?" question sidelined us, you were listing "as far as the actual design issues with STD"... 23:05
TimToady more likely $?PARSER, since it becomes a constant at run time
mncharity refactoring string sublanguage stuff; tracking relationships of various sibling sublanguages; ...? 23:06
TimToady the third one is basically the maundering in the comments at the front about how to use a language module and then derive from it, and how all the linkage works
such as, how do you tell the APL grammar to stop on an unmatched } :)
b_jonas that's what I tried to say above when I said "except for the closing brace" 23:07
TimToady indeed, the optimal situation is if all parsing is one-pass like that
b_jonas the APL grammar could stop on some closing marker native to apl, and then require a brace
or something
TimToady rather than trying to find the end of a quoted region and reparsing
b_jonas because just a closing brace could be valid in that language 23:08
TimToady this is a mistake p5 made on several levels, looking for the end of a construct and then reparsing
b_jonas TimToady: oh yeah, that's what ruby actually does differently in string interpolation 23:09
TimToady so yes, there has to be something that is the natural terminator in the sublanguage
b_jonas the interpolated code can contain the same quote marker
mncharity so of those, the ones standing between us and gimme5's output being able to parse say kp6 source files, is a*b propagation and regularizing Match/Return?
b_jonas or it can contain braces if it's inside expressions
TimToady p6 can do that too, now that we do everything one-pass
b_jonas but it's easier there because a closing brace (which closes the interpolation) is also a closing delimiter in ruby
whereas in a random langauge, it could be valid in itself
TimToady mncharity: well, and the fact that nothing is tested :) 23:10
mncharity testing I can do :)
TimToady but once I had the LTM stuff in hand I felt that the rest was mostly a small matter of programming
b_jonas I don't even know what the syntax should be for an embedded J expression 23:11
because the native closing delimiter in J would be a )
but then you still need the closing brace or it would look ugly
I guess it would be like 23:12
TimToady the OPP is a bit more complex than a standard binary-operator OPP, since it needs to take into account list precedence and such, but I think EXPR is close to correct there
b_jonas { use J;
foo
bar
)
}
TimToady s/precedence/associativity/
b_jonas: I'd say for something like that you'd rather have a macro that has its own idea of delimiters apart from {...} 23:13
b_jonas yep
TimToady just as a Python macro might just arrange to stop with sufficient outdent
mncharity re Match/Return, the options seem to be () hang info on the side ($<side> = whatever), () stuff info in scalar value stash, () operators return instances of a mutant Match class which stores the extra info, () ...something else..?
b_jonas maybe you'd embed small J snippets with a macro with a short name, like, j(foobar) 23:14
TimToady that would be preferable to either two-pass parse or bending {...} all out of recognition :)
b_jonas (though there's the more difficult problem of passing data in and out) 23:15
TimToady possibly solved with feeds 23:16
but there's no reason a macro could involve a call into a signature parser too 23:17
*couldn't
yet another of those little sublanguages :)
b_jonas well, you could call back p6 from j too, and then the only problem is conversion of data types 23:18
no need to share a namespace or anything like that
mncharity $<_opp_cruft_> = { :prec<...>, :assoc<...> } 23:19
$<_opp_cruft_> = $my_childs<_opp_cruft_>
$<opp_data> ;) 23:20
TimToady not sure what you're getting at, but sure, you gotta propagate stuff up to where the opp can see it somehow or other 23:21
23:22 gbarr_ joined
TimToady and there's some complexity involved in getting 1..100 :by(2) to attach the :by(2) to the .. 23:22
which is what "thisop" is about 23:23
mncharity I'm suggesting passing the opp info on the side, rather than make()ing it. and perhaps doing so with a single field, rather than having separate $<prec> and $<assoc> scattered.
s/scattered/inlined/ 23:24
TimToady which is pretty much back to the nature of coercion vs match objects again 23:26
it's quite probable that the objects' prec and assoc should be attributes and not hash values 23:27
in which case you're more like mixins
23:27 eternaleye_ joined
TimToady and the opp state is more like a role 23:28
mncharity I'm also a bit tempted by the locality of having a find_this_Match_objects_precedence() helper, which hypothetically digs down for the info, rather than what I worry might be an escalating set of rules being affected ("oh, were going to need the info there too, so we'll have to pass it trough x, and y, and z"). 23:29
TimToady which is, in fact, how it's written in STD at the PrecOp level, but we could extend that down further
mncharity so replace_current_Match_object_with(MatchMutant.new_from(current_Match_object,...random extra info...)) ? 23:31
TimToady but if you do that you have to either have the intelligence outside the reduction logic, or reenter it somehow
well, that's more or less what the current cursor code is doing anyway 23:32
though I don't remember to what extent the current cursor* methods that are checked in do that; my copy has diverged a bit 23:34
actually, it would have been the matchify code hauling the info along as pseudo match entries 23:36
mncharity if one generalize Match's name(), to point to the actual rule object, rather than just its name, then it would be unsurprising for the Match()s generated by operators to point to such an object, and to find prec/assoc information there.
TimToady was trying to avoid calling a method every time EXPR wants to compare prec or assoc, but it's probably a false economy 23:37
could cache those in the stacks anyway if they needed to be faster 23:38
mncharity so I guess that's a 4th option, () keep it in rul objects linked from an objectified name().
s/keep it/keep assoc/prec/ 23:39
TimToady 'course, now your little yaml dump of the match dumps the entire grammar :/
but that's probably just the problem of using yaml 23:40
rather than a more appropriate transform/emitter
likely it's easier to track a rule pointer through the cursor than various splatter'd values 23:41
mncharity currently works (i fuzzily recall). walks the tree, deleting such yaml-problematic nodes, before dumping. a custom emitter is probably more the "right thing" from a yaml perspective. 23:42
s/nodes/fields/
TimToady matchify is done at rule reduction time, so it doesn't complicate .prior tracking
(.prior only threads on actual bindings, not all intermediate states) 23:43
so collecting the match data should be fairly efficient, and we can manage the rule pointer at the same sequence points 23:44
23:44 devogon_ joined
mncharity name() should probably be objectified even if it isn't used for this, just so it can be used with anon rules. if you wan't the name, ask the rule for it. and how that interacts with rebinding... makes my head hurt. rb 1.9 has two separate bits of info available inside 23:44
a method - what name were you defined as, and what name were you called as. 23:45
TimToady um, "name" in Cursor5 is not the name of hte rule
it's the name we'll be bound to 23:46
mncharity oh? oops. hmm.
"the name we'll be bound to" in the enclosing Match object?
TimToady so ends up the key in the outer match obj's hash
but we don't have that hash yet 23:47
mncharity so our Match's have no memory at present of what rule created them?
TimToady so a cursor can remember the name it's being bound to, and matchify is what actually constructs the Match later
and only cursors with a "name" are threaded on .prior pointers 23:48
but we do need the rule pointer in any case, just for accountability and good error messages, so leaving the prec there might make sense. 23:50
gotta think about that in terms of whether it has any impact on grammar extensibility
mncharity re 'just for accountability and good error messages', it also makes subsequent use of the Match tree much easier. having a node self declare 'i am a variable!', rather than having to infer it from 'well, my parent has me in a field named x, and I myself have fields name y and z, so maybe I'm a variable?'. or 23:52
having the rules decorate the matches rule foo { ... {$<rule>=self}}. though if there was an easy way to make that happen, that would be fine too. 23:53
re extensibility, oh, hmm. 23:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!