> I have not used PettitParser yet, looks powerful but I find it a bit > weird in design. On the other hand regex is quite ugly and understanding > complex regex a pain. I normally encounter two issues with RegExps:
1) The syntax between different apps/libs/frameworks differs sligtly. Esp. for character classes or greediness. This drove me crazy more than one time. 2) Often enough I realize (while developing the RegExp) that I need something more capable than a Chomsky Type 3 parser (which RegExps are in a way). So I have to use "a bigger gun" - e.g. PetitParser.
CU, Udo On 23.09.14 10:15, kilon alios wrote:
it reminds a lot of Kent's Beck Smalltalk Practice Patterns where it removes all ifs and replaces them with regular unary messages . It is definitely an elegant way of coding making the code just flow. I have not used PettitParser yet, looks powerful but I find it a bit weird in design. On the other hand regex is quite ugly and understanding complex regex a pain. On Tue, Sep 23, 2014 at 11:07 AM, Udo Schneider <udo.schnei...@homeaddress.de <mailto:udo.schnei...@homeaddress.de>> wrote: > just as it is black magic for me now :D The nice thing about this approach is the fact that it "just" piggybacks the normal Smalltalk message sending. So you can step through it using the Debugger - it's Smalltalk all the way down. I still remember my first shock when (having no formal background on parsing theory at that time) I saw the parsing tables generated by T-Gen. Of course it was Smalltalk ... but understanding those tables was a nightmare. PetitParser is the gold standard here IMHO. It is able to parse arbitrary input (compared to my block expressions only). And you can still use the Debugger to step through the parsing process *and still understand what's going on!* CU, Udo On 23.09.14 09:54, kilon alios wrote: just as it is black magic for me now :D At least I get the general feeling. I am new to parsing too, so far I have only played with regex parsing. Not the most smalltalkish way but it works well so far. On Tue, Sep 23, 2014 at 9:39 AM, Udo Schneider <udo.schnei...@homeaddress.de <mailto:udo.schnei...@homeaddress.de> <mailto:udo.schneider@__homeaddress.de <mailto:udo.schnei...@homeaddress.de>>> wrote: Hi Estaban, I think the first time I saw this pattern was in ReStore on Dolphin Smalltalk. I didn't understand it's implementation back then. I assume that it's similar to what I described though. But having a Smalltalk block automagically creating the equivalent SQL SELECT expression was like black magic at that time :-) CU, Udo On 23.09.14 04:15, Esteban A. Maringolo wrote: Excellent article. I think GLORP uses a similar technique to setup its expressions, and also have issues with #and:/#or: selectors due to inlining, so it uses AND:/#OR: instead. Regards! Esteban A. Maringolo pd: Your blog and it's choosen topic made me remember http://use-the-index-luke.com/ 2014-09-22 20:48 GMT-03:00 Udo Schneider <udo.schnei...@homeaddress.de <mailto:udo.schnei...@homeaddress.de> <mailto:udo.schneider@__homeaddress.de <mailto:udo.schnei...@homeaddress.de>>>__: All, I just finished a blog entry. It shows how to use Smalltalk blocks as parsers/translators. E.g. translating a Block [:customer | (customer joinDate year is: Date today year)] into an SQL-like String (YEAR(customers.joinDate) = 2014) The SQL stuff is just an example - you can create nearly any output. Check out http://readthesourceluke.__blo__gspot.de/2014/09/block-____translators-parsing-magic.html <http://blogspot.de/2014/09/block-__translators-parsing-magic.html> <http://readthesourceluke.__blogspot.de/2014/09/block-__translators-parsing-magic.html <http://readthesourceluke.blogspot.de/2014/09/block-translators-parsing-magic.html>__> Maybe that's old stuff for some of you - but I hope it's interesting for some at least :-) Comments and feedback appreciated. CU, Udo
