Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-01-20

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

All times shown according to UTC.

Time Nick Message
23:02 jeffreykegler joined #marpa
03:52 mashalover joined #marpa
04:11 jeffreykegler left #marpa
05:27 ronsavage joined #marpa
07:08 jeffreykegler joined #marpa
07:18 jeffreykegler left #marpa
09:00 ronsavage left #marpa
12:54 jeffreykegler joined #marpa
12:55 jeffreykegler left #marpa
16:40 jeffreykegler joined #marpa
18:02 jeffreykegler I'm about to close out the "inter-phase" between phases 1 and 2 of the Marpa rewrite, and create a developer's release.
18:02 jeffreykegler That means issues which didn't make it into this inter-phase will probably need to wait for the next one.
18:03 jeffreykegler But I hope phases will be short -- just a few days.
19:16 LLamaRider joined #marpa
19:18 jeffreykegler left #marpa
19:38 ewmenida joined #marpa
20:03 jdurand joined #marpa
20:04 skalolaz joined #marpa
21:02 ronsavage joined #marpa
21:03 kaahome joined #marpa
21:31 jdurand ron, since you're here met le explain the inline assembly support in MarpaX::Languages::C::AST
21:31 jdurand I distinguish gcc inline assembly, and all the others
21:32 jdurand gcc inline assembly is just a hook that looks like a function call with crafted arguments that are strings separated by colons
21:32 jdurand (that's why some people complain, because it is painful to write inline assembly in GCC)
21:32 jdurand for all the others I assumed the MS ASM style for the moment, i.e.
21:33 jdurand first  case: asmKeyword { ... }
21:33 jdurand second case asmKeyword ... up to newline
21:34 jdurand In the first case I scan the buffer after the first '{' character per character because inline assemby has the (dis)advantage that is can contain
21:34 jdurand comments in both C/C++/ASM styles, and strings in the ASM style
21:34 jdurand the second case Is just a slurp up to newline
21:35 jdurand in conclusion: neither in GCC inline assembly nor in non-GCC inline assembly, there is a tentative to understand the ASM language
21:35 jdurand that's why it works in all cases for the GCC style, hopefully in all cases for the non-GCC style
21:35 jeffreykegler joined #marpa
21:36 jdurand hy jeffrey, you missed a technical explanation of inline assembly support one minute before you joined (!) - c.f. the logs -;
21:36 jeffreykegler Nope, just read it
21:37 jdurand I mean inline asembly support in MarpaX::Languages::C::AST
21:37 ronsavage jdurand: OK. I should have investigated both sets of code before saying anything :-(.
21:37 jeffreykegler I read the backlog, so I've just read your messages of a few minutes ago
21:38 jdurand ah ok -; I putted a stop on ASM parsing - I know how to parse it, an might continue MarpaX::Languages::MASM::AST OOTD - but the good news is that now the C grammar
21:38 jdurand of MarpaX::Languages::C::AST is not bloatedd anymore that the ASM language, that had nothing to do in here in fact
21:39 jeffreykegler jdurand: so this was sort of an exercise in factoring out MASM from the C grammar?
21:40 jdurand let's say it like that - I am happy to have literlly destroyed tens of rules in G1 and L0
21:40 jeffreykegler jdurand: that's a good thing.  :-)
21:42 jdurand Ineed. Now I canconcentrate back on JavaScript::Transpile, instead of navigating in the nightmare of an ASM with no formal *working* grammar all over the world (amazing, but that's the facts)
21:43 jdurand As you know I highly concentrate on grammars that has a single parse tree value, this is why I have not investigated in ASF up to now - its nice features is not a goal of mine up to now
21:44 jeffreykegler judrand: most parsing work will probably always be about producing a single value
21:45 jeffreykegler which reminds me
21:45 jeffreykegler are you interested in work toward a literate programming language,
21:45 jeffreykegler or meta-language
21:46 jdurand Definitely
21:46 jeffreykegler Because we have most of the pieces to do a better Cweb
21:46 jeffreykegler Some of the pieces of course we borrow from the existing Cweb.
21:47 jeffreykegler But Cweb's most complicated, and most creaky part is a C transpiler
21:47 jeffreykegler and we now have a much better one
21:48 jeffreykegler As an example of the limits of Cweb, have you ever noticed that I always start structure tags with "t_" in the C code?
21:48 jdurand ok, was reading wikipedia article on cweb
21:49 jeffreykegler Anyway, all my structure tags start with "t_".  The reason I do that is otherwise Cweb cannot tell them apart from other syntax.
21:50 jdurand ok
21:50 jeffreykegler And there's any number of things I have to do to help Cweb understand enough of my C syntax to format it.
21:51 jeffreykegler [ Same issue in texinfo, by the way, where you have to help the parser out by identifying the parameter names. ]
21:52 jdurand I see - the concepts are good, the implentation has flows
21:52 jdurand revisiting it with a meta language is a nice idea
21:52 jeffreykegler So, anyway, first step is a C indenter / pretty-printer, as I see it.  (I have in mind a incremental approach, where we add pieces, in the meantime working with Cweb as it is.)
21:53 jdurand oups, forgot I promissed this indenter...
21:53 jeffreykegler I say "meta-language" because you can set up so that the language is not necessarily C and you just plug in your Javascript transpiler or whatever.
21:54 jeffreykegler So your literate programming document could mix languages -- but that's getting ahead of ourselves.
21:54 jdurand understood
21:54 jdurand ok, I agree to work on that
21:54 jeffreykegler So the indenter is a first step in that direction.  Get the indenter, then get it so it understand the Cweb additions to C enough to format them
21:55 jdurand I was to write that: in the 1st phase the C indenter
21:55 jeffreykegler And then we have something more than smart enough to replace Cweb's C parser.
21:55 jeffreykegler And then go from there
21:56 jdurand ok - after we can think to something more ambitious
21:56 jeffreykegler Since it's initial target is Libmarpa, there's one arbitrary design restriction I feel I need ...
21:56 jdurand Sorry to have forgotten the C indenter stuff, will return to it and tell you
21:57 jeffreykegler And that is, that if worst comes to worst, I need to be able to compile without a working Marpa.
21:57 jeffreykegler So it's OK if I can't update the docs without a working Marpa, that's OK.
21:58 jeffreykegler But, parts of the literate programming system will have to avoid using Marpa.
21:58 jeffreykegler Ironic, but I think you see the reason -- otherwise, it's a disastrous circular dependency.
22:00 jdurand have you investigated in other C pretty-printers
22:00 jeffreykegler Yes, a little.  Why?
22:01 jdurand I wondered in the GNU indent would not have been what you're looking for - not beeing a Marpa product, but a GCC-style thingy
22:03 jeffreykegler I talk about this a bit in my blog post on your MarpaX::Languages::C::AST
22:03 jeffreykegler GNU indent, Cweb's own C parser, etc. don't know C very well
22:03 jeffreykegler They fake it.
22:04 jdurand ok, I see.
22:04 jeffreykegler If I use GNU indent, I might as well stick with Cweb's C parser.
22:04 jeffreykegler Which after all, was written by Don Knuth.
22:04 jdurand Ok, another question: the C source code that you want to indent
22:05 jdurand will it contain ony pure C or also include files, comments, etc
22:05 jeffreykegler Not sure I understand.
22:05 jeffreykegler Files?
22:05 jdurand preprocessor directives
22:05 jeffreykegler OK
22:06 jeffreykegler Yes, it will contain pre-processor directives and comments, etc.
22:06 jdurand ok, this is in the way I started writing it
22:06 jeffreykegler Also, it will often be fragments.
22:06 jeffreykegler As in several statements from inside a function but ...
22:07 jeffreykegler without the function "wrappings"
22:07 jdurand I don't understand this point - do you have an example
22:08 jeffreykegler For example, the code "a = 42;" -- that's not valid outside of a function.
22:09 jeffreykegler "int a = 42" would be valid as an external, because it's a declaration with an initializer ...
22:09 jeffreykegler but an assignment statement must occur inside a function.
22:11 jeffreykegler Note that perltidy faces this same issue -- unlike the Perl interpreter, it has to parse fragments of Perl --
22:11 jeffreykegler whereas the interpreter is free to reject anything that's not a valid, complete, Perl program
22:13 jdurand ok, so it is just a question of having another ':start' in the C grammar
22:13 jdurand having the grammar in front of me, it really looks like your input would just be exactly the equivalent of the body of a function
22:14 jdurand that is allowed, then, to have both declarations and statements
22:14 jdurand anyway, I propose that the C indenter would have an option to choose the "start", will hook the grammar for that -;
22:14 jeffreykegler You'd also perhaps want a fallback where the utility "round-trips" your source, even if it does not understand it.
22:15 jeffreykegler jdurand: Actually the tradition is to accept certain obvious things, which are natural to want, like declarations, statements and sequences of these.
22:16 jeffreykegler and to refuse to accept nonsense like the last half of a switch statement without the first half, or vice versa
22:17 jdurand no problem - understood - will continue the work on it and tell you
22:17 jdurand I remember having looked at the different "indent styles" on Wikipedia
22:17 jeffreykegler You versus Don Knuth -- should be fun :-)
22:18 jeffreykegler Knuth's C parser for Cweb is written up as Cweb, by the way
22:20 jdurand I will never compare to such brillant guy, but agree to take a trial on an implementation of something he designed -;
22:20 jeffreykegler The nice thing about an indenter, is that the work is less fussy.  An 1% failure rate in a compiler is a bit deal.
22:20 jdurand I am pretty sure to know well how to do it:
22:21 jeffreykegler Whereas an indenter with a 1% failure rate is still kind of useable.
22:21 jdurand the most general thing in what C calls a blockItemList, that is nothign else but the body of a function definition
22:21 jdurand such rule contains all the gory details of declarations *and* statements
22:22 jeffreykegler Knuth of course invented a lot of things without which I could not have done what I do --
22:22 jeffreykegler such as big-O style analysis of algorithms.
22:22 jeffreykegler judrand: if nothing else, blockItemList should be a great start.
22:23 jeffreykegler But I do believe we can improve on his Cweb C parser.
22:23 jdurand jefffrey, I had to go to wikipedia again, big-O was an unknown term for me
22:23 jdurand otherwise let's conclude by this planning
22:24 jdurand the C indenter, then and/or in the meantime you/me/others welcome think to cweb concepts improvements
22:24 jeffreykegler When I talk about linear being O(n), quadratic being O(n**2), that's big-O notation
22:24 jdurand Ah -; I feel a bit better
22:25 jdurand I am not a mathematician but was a physicist
22:25 jdurand so sometimes I understand -; !
22:25 jeffreykegler CERN is near where you live, isn't it?
22:25 jdurand Yes, I worked there 10 years, and my current place is still few miles from it
22:26 jeffreykegler You're not still there?
22:27 jdurand I retired, could explain you in private why if you want
22:27 jeffreykegler No, that's OK
22:27 jdurand anyway, after the PhD I moved there, 10 years, and is now in engineering computing since almost 10 years again
22:29 jdurand let's return to Marpa
22:29 jeffreykegler I think of myself as a mathematician.
22:29 jeffreykegler And so for me Marpa is first off an exercise in the math.
22:31 jeffreykegler I'd hoped to be the first mathematician to come out of nowhere after age 50, but Yitang Zhang stole that record from me a few months ago. :-)
22:32 jeffreykegler Yes, so I'm think with the literate programmer thing, not to get ahead of ourselves, but to proceed ...
22:32 jdurand Ah! Jeffrey, I think the community has acked that Marpa is a brillant thing
22:32 jeffreykegler worse-is-better, bit by bit
22:33 jeffreykegler I'm sort of isolated, so I have trouble following the sentiment ...
22:33 jeffreykegler which in the beginning was probably a good thing. :-)
22:33 jeffreykegler I'm live near Carmel CA, and here technology means an electric corkscrew.
22:35 jdurand Really (!?)
22:35 jdurand Sooner the better, we should work on a ambitious concrete thing, instead of just continuing the demonstration of Marpa power by providing grammars here, grammars there
22:35 jeffreykegler "concrete"?
22:37 jdurand something that does involve programmers, but architect or functional designers that must use an advanced program
22:38 jdurand ok, step by step - cpretty, my JavaScript::Transpile thing; and then I'll might propose a collaborative project
22:38 jeffreykegler The disadvantage is that if you take a "push" rather than "pull" approach, the community may not adopt.
22:38 jdurand oups, I menat: something that does NOT involve programmers
22:39 jeffreykegler Non-programmers are conservative when it comes to adopting programming technology ...
22:39 jeffreykegler and for that matter, when it comes to parsing, programmers are as well.
22:40 jdurand that's why I did not say users, but architect or functional designers - these are people in the middle, and these people are closer to the decision-makers, users are not
22:41 jeffreykegler My idea is, first, eat our own cooking ...
22:41 jeffreykegler and second, that user base, we have, take care of it.
22:43 jeffreykegler If we do an indenter, we (or at least I) will use it, and it will really help me ...
22:43 jeffreykegler and I'll add more features to Marpa, and they'll be a virtuous cycle started.
22:43 jdurand Fully agree - let's do it like that, step by step is the way to go
22:44 jdurand it's late here - time to repair some synaptics if possible while sleeping! See u
22:45 jeffreykegler Bye!

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