Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2016-05-13

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:22 idiosyncrat_ All traces of the NAIF are now removed -- files, objects, classes and methods for symbols, rules, grammars and recognizers.
00:23 idiosyncrat_ Next I next to refactor the semantics a bit, in preparation for extending the SLIF syntax.
00:24 idiosyncrat_ Some of the new SLIF syntax will require breaking rules into pieces, where the subrules assemble the children to mimic the original rule -- I have most of the semantics ops I need to do this, but not all.
00:51 ronsavage Go for it!
00:52 ronsavage Errr. I sent that before I saw the post about NAIF. I meant go for '!'!.
02:12 rns_ joined #marpa
02:17 rns_ idiosyncrat: re http://irclog.perlgeek.de/m​arpa/2016-05-12#i_12471286 -- if ( C )'s are used for quantified [*+?] grouping -- ( C )[*+?] -- only, then bare ( C ) looks like a syntactic error or at least need not to have any special semantics.
02:17 rns_ left #marpa
02:22 rns And using - or ! as a post-modifer for () to mean hiding as in ( C )! or ( C )- looks good and removs the need to have (! C D !) or (- C D -).
02:24 idiosyncrat_ rns: bare ( C ) will mean C is returned as an element of an array, rather than directly -- in effect a sequence whose minimum is 1 item, and whose maximum is one item.
02:25 idiosyncrat_ If Larry were designed this he'd probably be very open to making ( C ) a special case, rather than insisting it be orthogonal with (C)* and (C)+
02:25 idiosyncrat_ But my training is mathematics, rather than linguistics and non-orthogonality bothers me.
02:31 rns So bare ()'s -- as in ( C ) or ( C D ) -- will force ::array semantics on C or C D ?
02:36 rns Unquantified ()'s look suspiciously close to curlies in the current SLIF -- https://metacpan.org/pod/distributi​on/Marpa-R2/pod/Scanless/DSL.pod#Gr​ouping-statements-in-curly-braces -- just for visual clarity, syntax-only.
03:04 idiosyncrat_ rns: Well, different contexts, RHS's versus statement lists.
03:06 idiosyncrat_ Also, curly braces in the SLIF are *not* just for visual clarity -- the SLIF is lightly ambiguous, and it is possible that you would need them to dis-ambiguate it.
04:14 rns idiosyncrat: Fair enough, point taken. And using ! or - as a quantifier to mean 0 as ronsavage suggested above looks like a good idea.
04:26 idiosyncrat_ rns: Great.
04:26 idiosyncrat_ Just to reinforce my point, take the two cases
04:27 idiosyncrat_ A ::= ( B )
04:27 idiosyncrat_ and
04:27 idiosyncrat_ A ::= ( B ) ** 1 .. 1
04:28 idiosyncrat_ where the "** 1..1" is the Perl 6 quantifier syntax for a range from with min 1 and max 1
04:28 idiosyncrat_ It makes sense to me that they should have the same semantics.
04:34 rns A ::= ( B ) ** 1 .. 1 -- surely should. As for A ::= ( B ) -- only if ** 1 .. 1 is tacitly implied -- which I didn't capture.
04:37 rns Thanks for clearing that thing to me.
04:46 idiosyncrat_ Good night!
04:57 rns Good night.
05:28 rns left #marpa
05:52 ronsavage joined #marpa
06:42 pczarn joined #marpa
11:19 kaare_ joined #marpa
13:20 idiosyncrat_ joined #marpa
13:22 idiosyncrat_ Question to the IRC channel:
13:22 idiosyncrat_ As promised, I am changing the arguments to the semantic closures.
13:23 idiosyncrat_ Currently semantic closures for rules are called as
13:23 idiosyncrat_ closure(ppo, child1, child2, ....)
13:24 idiosyncrat_ where ppo is the per-parse object, and child1, child2, ... are the values of the child nodes.
13:24 idiosyncrat_ This is unless the rule is blessed, in which case its semantic closure is called as
13:25 idiosyncrat_ closure(ppo, children_array)
13:25 idiosyncrat_ where children array is an array containing the children: [ child1, child2, ... ]
13:26 idiosyncrat_ This inconsistency arose because when I introduced rule blessing, I needed something to bless, and lists cannot be blessed, only references to arrays.
13:26 idiosyncrat_ Marpa::R3 will fix this inconsistency -- all semantics closures will be called as
13:27 idiosyncrat_ closure(ppo, children_array)
13:27 idiosyncrat_ All this is background to the question.
13:27 idiosyncrat_ Now for the question:
13:28 idiosyncrat_ While I am at it, should I put the ppo 2nd instead of first, so that semantics closures are called as
13:28 idiosyncrat_ closure(children_array, ppo)
13:28 idiosyncrat_ ?
13:28 idiosyncrat_ The reason to do so would be that ppo, the per-parse object is not always used, so that the arguments
13:29 idiosyncrat_ could be unpacked as
13:29 idiosyncrat_ my ($children) = @_;
13:29 idiosyncrat_ whereas now that would have to be
13:29 idiosyncrat_ my (undef, $children) = @_;
13:29 idiosyncrat_ if your closure does not use the per-parse object.
15:26 JPGainsborough joined #marpa
16:13 maybekoo2 joined #marpa
16:30 kaare_ joined #marpa
17:09 idiosyncrat_ joined #marpa
18:07 kaare_ joined #marpa
18:29 idiosyncrat_ A 2nd question to the IRC channel:
18:31 idiosyncrat_ In Marpa::R2, there is a "reserved action name" ::first, which means that the value is the first non-hidden child value.
18:32 idiosyncrat_ I'd like to extend this, so you can request the first, second, etc., etc.
18:32 idiosyncrat_ What syntax to use?
18:32 idiosyncrat_ One possibility is ::0th, ::1th, ::2th, using the 'th' as a kind of ordinal ending.
18:33 idiosyncrat_ Here ::0th would be equivalent to ::first
18:34 idiosyncrat_ Other possibilities are pretty endless -- ::[0], etc.
19:29 idiosyncrat_ There's also ::0, ::1, but I worry they look a little 'spare'
22:22 idiosyncrat_ joined #marpa
22:51 koo7 joined #marpa
23:08 koo7 joined #marpa
23:31 idiosyncrat_ I notice the latest perlguts refers to the use of &PL_sv_undef in the XS code for undef values -- this reuses the same pointer for all undefs.
23:32 idiosyncrat_ That saves a little space, but requires the garbage checker to treat those locations specially, which is bad practice, no least because C89 does not guarantee pointer comparison.
23:33 idiosyncrat_ That is, if a and b are pointers, and both a and b point to the same locations, you *cannot* assume that a == b.
23:34 idiosyncrat_ At the time C89 came out, much C code ran on Intel chips like the 286, which has segmented memory, and that's why the restriction.
23:35 idiosyncrat_ Anyway, the Perl code used this and &PL_sv_undef  and code like "p == &PL_sv_undef" all over the place, and wouldn't work unless pointer comparison worked, but still it was pretty bad practice.
23:35 idiosyncrat_ Which I copied because when push comes to shove, the safest route in often imitation.\
23:37 idiosyncrat_ But now apparently the Perl 5 overlords have repented their careless past
23:37 idiosyncrat_ and they are sermonizing other folks: http://perldoc.perl.org/perlguts.html#AVs,-HVs-and-undefined-values
23:47 idiosyncrat_ That old saying about if they built building the way large programs are built, the first woodpecker would destroy civilization, comes pretty close to the truth.

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary