> 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.schnei...@homeaddress.de
<mailto:udo.schnei...@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.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>
<mailto:udo.schneider@__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>>
<mailto:udo.schneider@
<mailto:udo.schneider@>__homead__dress.de <http://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>>
<mailto:udo.schneider@
<mailto:udo.schneider@>__homead__dress.de <http://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://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
