> 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.schneider@homeaddress.de�� �� �� �� <mailto:udo.schneider@__homeaddress.de<mailto:udo.schneider@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.schneider@homeaddress.de
�� �� �� �� <mailto:udo.schneider@homeaddress.de>�� �� �� �� �� �� �� �� ��<mailto:udo.schneider@__homeaddress.de
�� �� �� �� <mailto:udo.schneider@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.schneider@homeaddress.de
�� �� �� �� <mailto:udo.schneider@homeaddress.de>
�� �� �� �� <mailto:udo.schneider@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