Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-05-11

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

All times shown according to UTC.

Time Nick Message
00:12 ronsavage joined #marpa
00:12 ronsavage JK: Re http://irclog.perlgeek.de/marpa/2017-05-10#i_14561378. 'are not allowed' => 'are now allowed'. Surely!?
00:14 ronsavage JK: Re: http://irclog.perlgeek.de/marpa/2017-05-10#i_14562064. I know it is a bit longer long but 'physical location' => 'input stream offset' is how I always think of it. And offsets  can start from 0, so that's OK.
00:15 ronsavage JK: IOW Your terminology may be L0 and G1, but I've always thought that's more of an implementation view, making sense to people with a certain type of background for sure, but rather abstract for some of us, i.e. me.
00:23 ronsavage JK: Re: http://irclog.perlgeek.de/marpa/2017-05-10#i_14562210. I think your logic is confused here. If read() is returning (say) a Boolean re it's success, it should not /also/ be indicating anything about (potential) events having being triggered. That would still give it double work, i.e. overloading. My 1st thought is: Return a Boolean, 1 => Success so entering the loop, 0 => Drop out. But warn the user they must still test for events af
01:06 ronsavage Damn. Msg chopped off at 'test for events af'. Repeating: But warn the user they must still test for events after the loop. And yes, there is a clear implication. Since there must also be testing for events inside the loop, that means 2 copies of that code, i.e. 2 calls to a block of event testing code. If you think that's a problem then at least keep it in mind while thinking about what read() should return.
01:50 ilbot3 joined #marpa
01:50 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste: http://scsys.co.uk:8002/marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
02:15 idiosyncrat joined #marpa
02:15 idiosyncrat Multiple $recce->read()'s are *NOW* allowed in Marpa::R3 -- I've just tested it
02:16 idiosyncrat Correcting http://irclog.perlgeek.de/marpa/2017-05-10#i_14561378
02:16 idiosyncrat ronsavage: Thanks!
02:18 idiosyncrat Re "physical location" vs. "L0 location" -- I've long had a problem with the terms "physical" and "virtual" in computing.
02:20 idiosyncrat When I started in the 1970's, there was (at least so we thought) a real meaning -- "in hardware" vs. "in software".  But now with optimized cache on top of optimized cache, no location accessible to a program is anything close to "physical" in any reasonable meaning of the term.
02:22 idiosyncrat I still will use it as a relative term.  That is, contrasted with "virtual" so that "virtual" means "less close to phyiscal" and "physical" really means "closer to physical than the virtual".
02:22 idiosyncrat But in the next rev of the Marpa::R3 docs, all references to a "virtual stream" will disappear -- they don't correspond to anything in the code, and they don't add anything conceptually.
02:23 idiosyncrat OTOH, "G1 locations" and "L0 locations" are, in fact, locations relative to the G1 and L0 recognizers, respectively, so they really do mean something fairly precise.
02:30 ronsavage joined #marpa
05:00 ronsavage I'm quite happy to ban usage of the terms physical and virtual, but since Marpa/Kollos can't possibly work without an 'input stream', I want to object to any elimination of that term.
05:03 ronsavage Events take place precisely because Marpa/Kollos detected a pattern at a particular place or span within that input stream. I think some of our difficulty here is that classic problem of forcing the user to focus on the technology underlying a process. This is what makes many Perl modules badly-named. Authors often make the mistake of naming their modules after the how and not the what. And yes, there are many (CGI, Telnet) when the how oug
05:05 ronsavage For Marpa/Kollos, the user-friendly interface should IMHO focus on the what it does rather than the how it does it. This in no way hides the underlying code, but just presents a less formal type of interface (at least in the docs).
05:30 sivoais joined #marpa
05:31 sivoais joined #marpa
06:12 idiosyncrat ronsavage: Here's the issue with an "input stream" -- it's difficult so bear with me.
06:13 idiosyncrat Consider parsing Perl code.  What's the input stream?  The Perl script in lexical order.  Easy, right?
06:13 idiosyncrat But now consider here-docs.
06:14 idiosyncrat To do these correctly, the parser needs to jump around in the file.  And this is something that occurs in other languages as well -- C, when you include the pre-processor for example.
06:15 idiosyncrat So now what is the "input stream".  If it's still the file, then the "input stream" is NOT the sequence of characters that the parser "sees".
06:16 idiosyncrat If we redefine the input stream, so that it's no longer the file in lexical order, but is something like the sequence of bytes the parser sees, our "input stream"
06:16 idiosyncrat 1.) becomes something which doesn't exists anywhere in the implementation; and
06:18 idiosyncrat 2.) becomes something which if we print it out in error messages (as in "your problem occurred here >> <<") is disorienting to the user -- the user will be oriented in terms of the original files, and not any sequence of bytes ...
06:18 idiosyncrat that results from jumping around to handle here-doc logic or macro expansion.
06:20 idiosyncrat The "input stream" idea works well for straight I/O (when UNIX introduced it, it was a revolution), but parsing requires taking a viewpoint one level above input streams.
06:22 ronsavage JK: Hmmm. OK. Proceed with what you think is right, but I'm afraid I'm not quite convinced :-). I did just want to register a complaint, though.
06:22 idiosyncrat Most of the time, you can say "L0 location, Jeffrey just means an input stream" and that will be accurate.  But when here-docs and macros get involved, it's no longer clear what I would be meaning if I talked about "input streams".
06:22 sirdancealot joined #marpa
06:23 idiosyncrat Do I mean the file which the user almost certainly thinks of as the "input stream", or do I mean the actual stream of bytes being parsed?
06:23 idiosyncrat If I say "L0 location", it can be very precisely and clearly defined what I mean.
06:23 ronsavage For me, the input stream is what gets fed into Kollos after macro expansion. And I can't yet visualize myself using here-docs within the input.
06:25 idiosyncrat ronsavage: Thanks for the feedback, which I'll keep in mind.  Maybe I'll discover that "input stream" really is a helpful concept which belongs in my docs, but I'll have to be able to define (at least to myself!) what I mean by it.
06:25 ronsavage E.g. If the macro was decode-utf-8 then Kollos would not see the utf-8 encoded data so the output of the decode would be the input stream.
06:26 ronsavage Anyway, it's good to toss these ideas around, even if my idea is not adopted as the Kollos-standard terminology!
06:27 idiosyncrat ronsavage: Again, thanks.
06:28 idiosyncrat But always in the docs, I have to ask myself whether I know what I am saying really means in all cases -- because if I don't, it's not likely anybody else will.
06:58 sirdancealot joined #marpa
08:24 ronsavage joined #marpa
09:00 sirdancealot joined #marpa
13:38 idiosyncrat joined #marpa
13:39 idiosyncrat I have just uploaded Marpa-R3-4.001_045
13:39 idiosyncrat This does *not* include any of the futures discussed in the last few hours.
13:40 idiosyncrat It *does* include the ability to call $slr->read() multiple times, each time starting a new input text block.
13:40 idiosyncrat So this is a new feature release!
13:43 idiosyncrat Internally, it's a big change, but the docs did not require much of a change: https://github.com/jeffreykegler/Marpa--R3/blob/master/cpan/pod/Scanless/R.pod#read
13:43 idiosyncrat There is an example of its use in the test suite: https://github.com/jeffreykegler/Marpa--R3/blob/master/cpan/t/block.t
13:57 sirdancealot joined #marpa
14:25 idiosyncrat CPANtesters looks OK (Andreas K's dirty dozen remain, but I'm assuming that's some blead-version test of his)
18:57 choroba joined #marpa
19:13 kaare_ joined #marpa
19:14 sirdancealot joined #marpa
19:59 kaare_ joined #marpa
20:47 kaare__ joined #marpa
23:10 ronsavage joined #marpa
23:15 ronsavage JK: Reading the docs for read(), my 1st thought was: Is there a new method (or other mechanism) to retrieve the value of the current block counter?
23:15 ronsavage JK: Re Marpa-R3-4.001_045. All tests pass here.

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