yeap noway I compare Regex with PettitParser. I will probably give a PettitParser a try, because I try to parse Pharo syntax to Python, I want now to parse Pharo classes to python class and that will be a nightmare with regex, so time to give PettitParser a serious try.

On Tue, Sep 23, 2014 at 1:10 PM, Udo Schneider <udo.schneider@homeaddress.de> wrote:

> 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>> 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
� � � � <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