Cool article & technique indeed. Ah Smalltalk, where were you all those years ;-)
Speaking of PetitParser, which is excellent indeed, there is this #==> method in Boolean. PetitParser uses that a lot. I can use the thing but do not really grasps how it works. Now, the method comment says: Boolean #==> aBlock "The material conditional, also known as the material implication or truth functional conditional. Correspond to not ... or ... and does not correspond to the English if...then... construction. known as: b if a a implies b if a then b b is a consequence of a a therefore b (but note: 'it is raining therefore it is cloudy' is implication; 'it is autumn therefore the leaves are falling' is equivalence). Here is the truth table for material implication: p | q | p ==> q -------|-------|------------- T | T | T T | F | F F | T | T F | F | T " ^self not or: [aBlock value] This is still a bit foggy to me. Anyone caring to shed some light on that? What are the typical ways to use that? TIA Phil On Tue, Sep 23, 2014 at 10:07 AM, Udo Schneider < 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>> 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>>__: >> >> >> 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.__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 >> >> >> >> >> >> >> >> >> > > > >
