Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-21

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

All times shown according to UTC.

Time Nick Message
05:51 jeffreykegler joined #marpa
05:52 jeffreykegler jdurand: As of commit e37ccb46a9a1032cb06ff9a012c0698339f322fd, I've added a marpa_g_force_valued() call, which in effect turns off valued vs. unvalued symbols for everything derived from that grammar.  It replaces the marpa_v_force_valued() call.
05:53 jeffreykegler I've also updated api.texi, not just to include marpa_g_force_valued(), but to move all details of the valued/unvalued feature into the (brand new) "Deprecated" section of the document.
05:54 jeffreykegler marpa_g_force_valued() is in the main non-deprecated section, with the grammar constructor.
05:57 jeffreykegler The story of valued and unvalued tokens might be filed under "Perils of using measurement to optimize".  By any reasonable measure, eliminating callbacks offered the biggest returns for optimization, and a large number of the callbacks were unnecessary because they were to return "don't care" values.  And thus were specially-marked "unvalued" tokens born.
05:58 jeffreykegler But as time progressed, I was pecked to death by little details.  Every bit of code that touched token values needed special logic to deal with the "unvalued" situation.  And in the meantime, alternatives to callbacks appeared and the performance bottlenecks moved.
05:59 jeffreykegler So moral of the story is perhaps "Measurement: you shouldn't optimize without it, or with it"
06:13 ronsavage joined #marpa
13:41 LLamaRider joined #marpa
16:51 jeffreykegler joined #marpa
16:53 jdurand joined #marpa
16:53 jdurand To help marpa C development I wrote a generic stack layer, i.e. https://github.com/jddurand/libmarpa-pack​aging/blob/master/examples/genericStack.h
16:54 jdurand It is generic in the sense that it has no notion of the type of data pushed on the stack.
16:55 jeffreykegler That's a good idea.
16:56 jeffreykegler Libmarpa is a level deeper, it returns the desired stack operations as events, which is an unusual system ...
16:57 jeffreykegler but it allows different users to define the stack differently.
17:03 jdurand Yes, I understood that. I wrote this layer kepping in mind the recommendations in Marpa's API, in particular the important point saying that teh stack should always have one first element. All the rest is generic decoration as far as C can permit -;
20:04 jeffreykegler Re Libmarpa's stack handling, I'll add another for the others readers (I'm pretty sure jdurand already sees this) ...
20:06 jeffreykegler The point of allowing the stack to be defined differently -- in writing Libmarpa I was initially presented with a choice -- assist the user in taking the completed parse and evaluating it, at the expense of tying Libmarpa to a particular type of data and therefore a particular upper layer language ...
20:07 jeffreykegler or of leaving everything up to the user, forcing the user to confront the tricky issue of evaluating sequence rules.
20:08 jeffreykegler I found a third way, that let's me have it both ways.  Libmarpa returns eventsthat tell the user what stack operations to perform.
20:09 jeffreykegler As in "take the items at positions 42-46, evaluate them using the semantics for rule 711, and put the result at position 42".
20:10 jeffreykegler This allows the upper layer to be Perl, or Python, or Ruby, each with a different data type, but each still benefiting from Libmarpa's evaluation smarts.
20:12 jeffreykegler Jean-Damien's new layer "un-abstracts" a bit -- it performs the stack operations as suggested by Libmarpa, but allows you to specify what the data is.
20:15 jeffreykegler It's an "un-abstraction" that might well have been better to include in Libmarpa, but in designing Libmarpa, I decided that, if I was facing a situation where it wasn't clear which was right, to be low-level, or to un-abstract to a higher level ...
20:16 jeffreykegler and if Libmarpa itself added no serious value in between, as in this case where how to perform stack operations is well known, and not something new with Libmarpa ...
20:16 jeffreykegler I would take the risk of erring on the side of staying low-level.
20:17 jeffreykegler My idea was, that if I went high-level, the user was stuck with my choices, but if I went low-level, that was a mistake the user could straight-forwardly fix.
20:53 jdurand Jeffrey, current libmarpa design is fine with me, that was a good choice
20:54 jdurand I mean: stack implementation is per-def a user-application layer, despite eveyrbody would naively think since the term stack is bloated with the notion of "stack" in subroutines
20:54 jdurand In the case of Marpa, the stack is really a user-stack, therefore letting the user dealing with that makes sense.
20:55 jdurand In a C++ world, push_back and al. might be useful. In a C world, a library like mine. In a perl callback word, simplu push() and pop() and so on
20:55 jdurand Nevertheless C beeing what it is, I believe there is a need for a user-level stack helper
20:58 jdurand in conclusion: I have nothing to bad to say with libmarpa right now - it is a pleasure to work with it, and I am pretty sure pure-C applications will perform very fast, hoping the comparison with other libraries will finally put Marpa in the top-level place -;
20:58 jeffreykegler My remarks just previous were largely intended for others trying to understand what is going on.  Libmarpa might wind up being like TeX which is now rarely used in its "raw" form -- almost always there is *some* kind of upper layer, and often several.
20:58 jdurand No pb. From development point of view, I currently believe that the current best trend is:
20:58 jeffreykegler Usually the upper layer is LaTeX, which in turn is often layered upon.
20:59 jdurand - develop in Perl using Scanless
20:59 jdurand - if happy with it, let with it
20:59 jdurand - if searching for in-depth optimisation, go to XS
20:59 jeffreykegler Cweb, which I use for the Libmarpa code, is an alternative upper layer.
21:00 jdurand -f if again more i;e. get rid of perl latency itself between XS and perl intepreter, move to C
21:00 jdurand ABout teX, LaTeX, CWeb etc... yes, and this makes it difficult to follow, to understand when it fails, sometimes -;
21:01 jdurand Back ot my development trend:
21:01 jdurand - Experiment with Thin interface if C could be a target
21:02 jdurand - Take advantage of grammar introspection facility in perl to *generate* the C code (what I have done in fact for the XSUB layer of XML, and I plan to reuse with the pure C application)
21:02 jeffreykegler One thing Libmarpa does have a pretty fancy error handling facility -- frankly it's better than Perl's.
21:02 jeffreykegler Libmarpa errors have error codes, which are guaranteed not to change, so the upper layers can rely on them.
21:03 jeffreykegler1 joined #marpa
21:05 jdurand Yes, that's very good. Right now I am systematically calling marpa_g_error_clear(g) before doing a check on the return code. Is that superflous ? C.f. e.g. https://github.com/jddurand/libmarpa-pack​aging/blob/master/examples/thin_macros.h
21:05 * jdurand is thinking Jeffrey is yelling bad words towards its internet connection -;
21:05 jeffreykegler1 The mnemonic for the error code is also guaranteed not to change, even if it becomes misleading or wrong, so the upper layers can rely on it.
21:05 jeffreykegler1 Perl has the problem that if you change the punctuation in an error message, you run the risk of breaking every app which tries to catch lower level errors.
21:06 jeffreykegler1 Calling marpa_g_error_clear is usually not necessary.
21:07 jeffreykegler1 The usual routine (and the standard one) is to expect the error code is have a meaninful value only immediately after a method which specifically returned failure.
21:08 jeffreykegler1 In which case marpa_g_error_clear() is completely unnecessary.
21:08 jdurand Alike errno more or less - ok fine with me
21:08 jeffreykegler1 Yes, exactly, like errno.
21:09 jeffreykegler1 Sometimes programmers try tricks that rely on checking the error code for non-error.  Usually they are best advised to overcome this urge ...
21:09 jeffreykegler1 but if they cannot, marpa_g_error_clear() is there to help them.
21:10 jeffreykegler1 To explain why I bothered with marpa_g_error_clear() -- I needed it for testing.
21:10 jeffreykegler1 And with it already written and *tested*, it cost nothing to add to the interface.
21:11 jeffreykegler1 jdurand: by the way, I did not take your comments on the interface in a negative way, and my followup remarks were simply explanations I hoped would be helpful to readers of this channel.
21:12 jdurand No pb - did not thought you might have think that I though that -; (hmmm !)
21:13 jeffreykegler1 I find it's often easier to work with a program/interface is you know why it came to be the way it is ...
21:14 jeffreykegler1 which is a big advantage us older folks have with Unix.  It actually all makes a sort of sense to us, because we know the history.
21:15 jeffreykegler1 To a newcomer, especially one with an active, questioning mind, I have to think Unix's interface must seem pretty inexplicable.
21:15 jdurand Definitely. One might assimilate to experience with programing, and experience is a mixture of knowledge of history and time spent on working on the associated are.
21:15 jdurand I will try to move on to something productive in my next spare times - either XS or pure C - I'll keep the list/IRC in touch
21:16 jeffreykegler1 AFK
21:16 jdurand "might assimilate that to ./.."
21:16 jdurand ok bye
21:17 jdurand "the associated area" - sorry for these  typos - bye
21:18 jeffreykegler1 jdurand: I look forward to seeing what you do next.

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