Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-02-22

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

All times shown according to UTC.

Time Nick Message
00:06 jeffreykegler I have uploaded Marpa-R2 2.103_008 to CPAN
00:07 jeffreykegler It contains the discard events *with* documentation:
00:07 jeffreykegler https://metacpan.org/pod/release/JKEGL/Marpa-R2-2​.103_008/pod/Scanless/DSL.pod#Discard-pseudo-rule
00:07 jeffreykegler https://metacpan.org/pod/release/JK​EGL/Marpa-R2-2.103_008/pod/Scanless​/DSL.pod#Discard-default-statement
00:07 jeffreykegler and
00:08 jeffreykegler https://metacpan.org/pod/release/JKEGL/Marp​a-R2-2.103_008/pod/Event.pod#Discard-events
00:09 jeffreykegler It might be a release candidate, but I may want to wait for the work on Libmarpa nits to finish, I'm not sure.
00:09 jeffreykegler Anyway, now you really can get started with discard events -- it should be 100% working and documented with this release.
00:10 jeffreykegler And testing is appreciated!
00:23 Aria jeffreykegler: Deep cloning (http://irclog.perlgeek.de/m​arpa/2015-02-19#i_10139783 ) ... I agree completely. They're never what I want. And copies are expensive. Languages that expose immutable data structures are interesting that way, but the difference is meaningless then.
02:47 ilbot3 joined #marpa
02:47 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Pastebin: 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
04:47 ronsavage joined #marpa
05:37 ronsavage Something's wrong with Marpa::R2 V 2.103_008:
05:37 ronsavage ron@zigzag:~/Downloads/Marpa/Marpa-R2-2.103_008$ build.install.sh
05:37 ronsavage Created MYMETA.yml and MYMETA.json
05:37 ronsavage Creating new 'Build' script for 'Marpa-R2' version '2.103_008'
05:37 ronsavage Building Marpa-R2
05:37 ronsavage Writing version files
05:37 ronsavage cc -I/home/ron/perl5/perlbrew/perls/perl​-5.20.2/lib/5.20.2/x86_64-linux/CORE -DVERSION="2.103_008" -DXS_VERSION="2.103_008" -fPIC -c -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I /home/ron/Downloads/Marpa/Marp​a-R2-2.103_008/libmarpa_build -I xs -Wall -W -Wpointer-arith -Wstrict-prototypes -Wwrite-strings -Wmissing-declarations -ansi -Wdeclaration-after-statement -O2 -o l
05:37 ronsavage lib/Marpa/R2.xs: In function ‘XS_Marpa__R2__Thin__SLR_g1_lexeme_complete’:
05:37 ronsavage lib/Marpa/R2.xs:6607:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
05:37 ronsavage Using built-in Libmarpa
05:37 ronsavage ExtUtils::Mkbootstrap::Mkbootstrap​('blib/arch/auto/Marpa/R2/R2.bs')
05:37 ronsavage cc -shared -O2 -L/usr/local/lib -fstack-protector -o blib/arch/auto/Marpa/R2/R2.so lib/Marpa/R2.o /home/ron/Downloads/Marpa/Marpa-R2-2.1​03_008/libmarpa_build/.libs/libmarpa.a
05:37 ronsavage cc: error: /home/ron/Downloads/Marpa/Marpa-R2-2.10​3_008/libmarpa_build/.libs/libmarpa.a: No such file or directory
05:37 ronsavage error building blib/arch/auto/Marpa/R2/R2.so from lib/Marpa/R2.o /home/ron/Downloads/Marpa/Marpa-R2-2.1​03_008/libmarpa_build/.libs/libmarpa.a at /home/ron/perl5/perlbrew/perls/perl-5.20​.2/lib/5.20.2/ExtUtils/CBuilder/Base.pm line 323.
05:37 ronsavage All prerequisites satisfied
06:30 jeffreykegler joined #marpa
06:32 jeffreykegler ronsavage: Interesting.  FWIW, cpantesters is 100% all OK so far, on 45 out of 45 platforms, including Cygwin, Windows, FreeBSD and Linux.
06:46 jeffreykegler joined #marpa
06:47 jeffreykegler ronsavage: 2 of the successful cpantesters test are for your configuration: x86_64-linux, Perl 5.20.2
06:48 jeffreykegler The message is from the compiler about the macro INT2PTR, which in XS is documented to convert int's to pointers -- it indicates that this macro is failing.
06:49 jeffreykegler Is it possible you've got a bad Perl build?
07:51 rns joined #marpa
07:54 rns ronsavage: re http://irclog.perlgeek.de/m​arpa/2015-02-22#i_10155725 -- no such warning in my setup under windows (msvc2010) and cygwin (gcc 4.9.2).
07:55 rns Both use Config::AutoConf -- you can force it with
07:55 rns MARPA_USE_PERL_AUTOCONF=1 cpan J/JK/JKEGL/Marpa-R2-2.103_008.tar.gz
07:56 rns left #marpa
10:06 pczarn joined #marpa
10:39 basiliscos joined #marpa
11:22 lwa joined #marpa
11:55 basiliscos joined #marpa
15:00 basiliscos joined #marpa
15:11 basiliscos joined #marpa
15:24 aredridel joined #marpa
15:25 sadmac joined #marpa
16:50 jdurand joined #marpa
18:17 basiliscos joined #marpa
19:20 jeffreykegler joined #marpa
19:20 jeffreykegler I've had a chance to glance at Jean-Damien's new M4 module.
19:21 jeffreykegler When you something like Marpa, which is a tool, the most pleasant experience you can have is seeing it used in a way you would not have anticipated.
19:22 jeffreykegler Jean-Damien uses the SLIF, but without internal scanning -- only external scanning.  This is something I'd anticipated -- it's mentioned in the docs.
19:26 jeffreykegler But, additionally, to make it do macros, which are continually expanding their input, he (if I am reading correctly), builds the input on the fly.
19:27 jeffreykegler And what the Marpa parser actually sees is a very virtual input, which it uses to keep track of the macros --
19:27 jeffreykegler This virtual input is *NOT* the physical input, as it includes macro expansions.
19:28 jeffreykegler But it is also not the eventual output, because once all macros are fully expanded, Jean-Damien does not bother feeding the result to Marpa -- there's nothing to parse.
19:29 jeffreykegler [ All this is assuming I am reading the code correctly ]
19:30 jeffreykegler The parse is never evaluated.  Instead, events are used and the output is built up as the parse tree of the extra-virtual input is created.
19:30 jeffreykegler Once the recognizer has consumed all of the extra-virtual input, the output is complete and there is no need to go on to the later stages.
19:30 jeffreykegler jdurand: how much of this did I get right?
19:59 jeffreykegler joined #marpa
20:01 jdurand joined #marpa
20:01 jdurand Re http://irclog.perlgeek.de/m​arpa/2015-02-22#i_10157741 - good analysis
20:02 jdurand Both the input and the outputs are moving targets
20:02 jdurand and yes, the SLIF is 100% used with an external lexer
20:02 jeffreykegler I believe this is a totally new parsing technique
20:03 jdurand The top-level of the grammar per def does not need evaluation, so its output is appended directly to a "value" that I maintain internally
20:03 jdurand The "inner" levels means per definition: macro arguments expansions or macro call result
20:04 jdurand I /use/ Marpa to get right the "value" of the arguments expansion, but only from a contextual point of view
20:04 jdurand the main thing, perhaps new indeed, is that SLIF is never used to read for me, I read everything for it
20:05 jdurand Glad you like that -;
20:05 jeffreykegler No, purely external scanning is mentioned in the docs, so that part is not new.
20:05 jeffreykegler Much of the rest, however, is stuff I never dreamed of.
20:05 jdurand Oh
20:06 jdurand Maybe the notion of input that is constantly changing is something very interesting
20:06 jdurand I managed to get that hopefully right and mimize the recursion as much as possible
20:06 jeffreykegler If I understand correctly, the input stream Marpa sees is neither the original input, or the eventual output.
20:07 jdurand In any case: yes, with one exception
20:07 jdurand when the input is composed of keywords that will never expand
20:07 jdurand then input == output
20:07 jeffreykegler But the macros expanded recursively, with all expansion kept but the last -- the one that cannot be expanded further.
20:08 jdurand Ahh... hmmm, how to say
20:08 jdurand if I have macros A and B and C like that:
20:08 jdurand A(B(C(x),y),z)
20:09 jdurand then there is a recursivity of three because of arguments collections, yes
20:09 jdurand Basically I say:
20:09 jdurand A(...) --> ???
20:09 jdurand parsing of what is inside the (...)
20:09 jdurand replace A(...) entirely by its output
20:10 jdurand not so hard, but one have to extremely precise with positions
20:10 jeffreykegler I'll bet. :-)
20:11 jeffreykegler So the actual input stream to G1 is hard to describe, but it all nexts, so it all follows the structure of the grammar.  Is that right?
20:11 jdurand There is a very deep difficuly with M4, though
20:11 jeffreykegler s/all nexts/all nests/
20:11 jdurand the notion of internal token: sometimes an arguments is allowed to be something else but characters, but an opaque object
20:12 jeffreykegler Opaque?
20:12 jdurand and this can happen only in few situations, typically when you say: define(`X', defn(`builtin_macro'))
20:12 jdurand ==> the output of defn(`builtin_macro') is the internal definition of macro "builtin_macro"
20:12 jeffreykegler Ah, OK, I see.
20:13 jdurand i.e. a coderef -;
20:13 jeffreykegler Right?
20:13 jdurand In my case, this is an object
20:13 jdurand that is fed directly into Marpa
20:13 jdurand and that I recuperate when I call the value of arguments collection
20:14 jeffreykegler I think that new languages could be designed around this technique.
20:14 jdurand but now the more deeper difficulty:
20:14 jdurand defn(`builtin_macro') is allowed also at the top-level
20:14 jdurand then the output should be... empty
20:15 jdurand i.e. the value of a macro expansion can depend of (1) the caller, (2) the arguments position from the caller point of view
20:16 jdurand that's why at line 603 (https://github.com/jddurand/MarpaX-​Languages-M4/blob/master/lib/MarpaX​/Languages/M4/Impl/Parser.pm#L603) I localize the object describing the caller
20:17 jdurand and this is also why the value of arguments collection, is done via an object helper that has a "concatenation" method that depends on both the caller and the target position in the caller's argument collection
20:18 jdurand i.e. https://github.com/jddurand/MarpaX​-Languages-M4/blob/master/lib/Marp​aX/Languages/M4/Impl/Value.pm#L55
20:18 jeffreykegler Re new kinds of language -- previously it's been LISP vs. ALGOL -- with this technique you can do both.  Write code that looks like ALGOL, but works like LISP.
20:21 jeffreykegler This approach can also be used for Marpa-powered interpreters in general.
20:22 jdurand Oh... this "opaque" token has a very strange label in the grammar: "ANYTHING" -; anyway, this was the real difficuly - all the rest was spent trying to do something OO that fitted what I think it has to be
20:22 jdurand yes, I think so
20:23 jeffreykegler Maybe you've invented a hammer that will be the start of a lot of very powerful new nails.
20:24 jdurand who knows! I leat I said to myself that I know how I could write the c preprocessor - which I definitely much simpler than M4
20:24 jeffreykegler Was doing a Marpa-powered C preprocessor the original motivation for taking on M4?
20:25 jdurand ahem, yes
20:26 jeffreykegler I look forward to your blog post.
20:27 jeffreykegler Did you get what I am driving at about languages that look like ALGOL and work like LISP?
20:28 jdurand probably this week - the current TRIAL release is failing and I know where - something very special with M4 (again) that tries to bypass and/or predict undefined behaviour of integer arithmetic
20:28 jdurand to be frank, jeffrey - no I have not understood
20:29 jeffreykegler OK.  Since your macro parsing is Marpa-powered, there is no longer the same need for all those parentheses which make languages like M4 and LISP so unnatural to read.
20:31 jeffreykegler M4 and LISP and the C preprocessor statements have the over-punctuated look they have because of the limits of the parsing.
20:31 jeffreykegler But with this technique you can do something like:
20:32 jeffreykegler if (a + b > 42) then if (z == zebra) then answer = 1729 fi fi
20:32 jeffreykegler where the first "if" is interpreted and the second one is not.
20:33 jeffreykegler that is, you abolish the syntactic distinction between preprocessing and parsing.
20:33 jdurand Ok. Understood.
20:33 jdurand Indeed, the first fi will be seen to in the context of the first if, the second fi is just a normal word, that is expanded as-is
20:33 jeffreykegler Right.
20:34 jeffreykegler So now all those fancy LISP-based techniques can be done in the your extended C compiler, via layers of pre-proprocessing.
20:35 jeffreykegler And with a unified syntax.
20:35 * jdurand is having a smile -;
20:36 jeffreykegler I don't know about you, but I'd like programming in a language like that better than anything out there ...
20:36 jeffreykegler or anything currently planned.
20:38 jdurand I follow that, and admit that in the last weeks I was thinking digging in my "own new" language
20:38 jdurand but I resisted
20:39 jeffreykegler Improved the M4 syntax, you mean.
20:39 jeffreykegler s/improved/improving/
20:39 jdurand first, yes - then thinking to something new
20:40 jeffreykegler It does help get the idea through if you originally stick to the standard.
20:40 jdurand but I am not expert enough, and believe have not enough experience, in enough languages to be able to dive right into this
20:40 jdurand but you're right - extending M4 is good
20:41 jeffreykegler I hope others are following this, and that this gives them ideas.
20:42 jdurand So do I! Ok I have to prepare for the coming business week by going to sleep - this week I will probably find time to fix the 1 over 133 (Grrrrrrrrr) test failure occuring massively with CPAN testers
20:42 jdurand then blog post -;
20:42 jeffreykegler Great.  bye.
20:42 jdurand Nice reading for those wanting to investigate how M4 is done -; AFK
20:42 jeffreykegler AFK
21:08 jdurand joined #marpa
21:09 jdurand Back few secs realizing I was no answering to http://irclog.perlgeek.de/m​arpa/2015-02-22#i_10158033
21:10 jdurand yes, that is correct. the subtility if that everything that is after current lexeme follows some rules, the current lexeme itself cannot be predicted in advance
21:10 jdurand AFK again
21:35 ronsavage jk: Re http://irclog.perlgeek.de/m​arpa/2015-02-22#i_10155841. So far nothing else has failed, but I've just started using it.
22:51 jeffreykegler joined #marpa
22:52 jeffreykegler I'm thinking about Jean-Damien's new approach in SLIF external input, and taking the liberty of trying to name it.
22:52 jeffreykegler I think perhaps "fractal input" would be best.
22:53 jeffreykegler Alternatives I thought of were Droste input, or Russian doll input.
23:08 ronsavage Auto-expanding input sounds better to me. Fractals are self-same at any depth, but with parsing you can't have infinitely-nested macros, surely, or you'd never stop expanding them, in which case the code will appear to loop for ever.

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