> 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.
Without wanting to go too deep into theory... Parsing Pharo or Python would definitely need a Chromsky Type 2 language (Context free grammar). So you'd be out of luck parsing Smalltalk or Python code with Regular Expressions (Chromsky Type 3) only - except maybe for some very simple expressions.
CU,
Udo
On 23.09.14 13:35, kilon alios wrote:
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<mailto: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>� � � � � � � � �<mailto:udo.schneider@� � � � <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>>
� � � � <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>� � � � � � � � � � � � � <mailto:udo.schneider@
� � � � � � � � �<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>>
� � � � <mailto:udo.schneider@>__homead__dress.de <http://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://blo__gspot.de/2014/09/block-____translators-parsing-magic.html>
� � � � <http://blogspot.de/2014/09/__block-__translators-parsing-__magic.html
� � � � <http://blogspot.de/2014/09/block-__translators-parsing-magic.html>>
� � � � <http://readthesourceluke.__bl__ogspot.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