Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-05-23

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

All times shown according to UTC.

Time Nick Message
00:06 jeffreykegler joined #marpa
03:04 jeffreykegler rns (but also others): I am approaching the point at which I have to deal with location issues in the KLOL -- for my JSON lexer.  As I think you already know, I envision a kind of object where the prototype includes all the constant data, not just methods, but also the input string itself.  From this prototype ("class") we create cursors, readers and markers of locations and spans for error messages, tracing, etc.
03:05 jeffreykegler Each input string is in a sense a class, and the locators themselves are then families of classes.
03:06 jeffreykegler [ For those not studying Lua, it's class model is interesting -- it provides few facilities, but those it provides make convenient building blocks, not just for conventional classes, but for other things ...
03:06 jeffreykegler although with all the class models out there, I have to believe what I am describing has already been thought of by *somebody* ]
03:07 jeffreykegler The word "class" here is used loosely since Lua does not really have classes as such.
03:08 jeffreykegler Each prototype has all the methods for being a cursor, a marker, a substring, a reader, etc.
03:08 jeffreykegler The actual object contains fields that the methods used, and which methods are allowed is dictated by which fields are defined.
03:09 jeffreykegler For example, if you want to call cursor methods, the "cursor_location" field must be defined.
03:10 jeffreykegler When a method is called but it required fields do not exist (which can happen if the object is of the wrong "type"), it is a fatal error.
03:11 jeffreykegler For efficiency (for example when the lexer is reading) I will allow the application to pull out the actual string so you don't have to call object methods for every character.
03:12 jeffreykegler Assumed here (at least for the moment) is that 1.) the string stays fixed once the object is created
03:15 jeffreykegler Actually I think 1.) may be it.
03:15 jeffreykegler I was going to say something about threading, but I think if we keep the string fixed that suffices.
03:16 jeffreykegler Some day we may want to extend to location objects which allow the string to be modified, but this model has worked OK in the SLIF, so it should do for now.
04:28 Aria That sort of prototype-as-basis is interesting!
05:09 ceridwen idiosyncrat: I'm not sure I completely understand it, but that Lang paper attacks the problem from an interesting direction.
07:37 lwa joined #marpa
11:43 sivoais joined #marpa
14:49 rns jeffreykegler: re http://irclog.perlgeek.de/m​arpa/2015-05-23#i_10646689 -- this is pretty much in line with the design notes about locations objects -- https://github.com/rns/kollos-luif-doc/bl​ob/master/etc/internals.md#implementation which I'm prototyping in https://github.com/rns/libmarpa-bindin​gs/blob/master/lua/kollos/location.lua
19:37 koo6 joined #marpa
20:03 jeffreykegler joined #marpa
23:41 ronsavage joined #marpa

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