On 23.09.14 02:27, Ben Coman wrote:

Very nice write up. Fairly straight forward to follow but not something I could have done from scratch. Nice to have a recipe for it. Thanks

One spelling mistake...

...

This will give es enough clues This will give us enough clues Thanks for the feedback - the spelling mistake is fixed.

Thanks, Udo

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

...

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

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

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>> 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>>__:

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-m... <http://readthesourceluke.blogspot.de/2014/09/block-translators-parsing-magic...>

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

MarkupBuilder in Groovy uses similar logic #doesNotUnderstand: .. but not debug capable ..!.. On Tue, Sep 23, 2014 at 1:45 PM, kilon alios <kilon.alios@gmail.com> 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> 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>> 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>>__:

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

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-parsi... <http://blogspot.de/2014/09/block-__translators-parsing-magic.html>

<http://readthesourceluke.__blogspot.de/2014/09/block-__translators-parsing-m... <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

2014-09-23 13:35 GMT+02:00 kilon alios <kilon.alios@gmail.com>:

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.

Kilon, just remember that you have a full Smalltalk parser already in your image, called RBParser. For Python parsing, there is probably a PetitParser based parser somewhere and two implementations of a SmaCC-based Python parser (For Python 2.7.X). Thierry

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

2014-09-23 13:57 GMT+02:00 Udo Schneider <udo.schneider@homeaddress.de>:

...

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.

Confirmed in even a better way: given how convoluted and hacky is writing a full Python Parser, it is probably not even a Context Free Grammar. That is: the Python grammar is LALR which is a subset of Context Free Grammar (but already more than a type 3 Chomsky grammar), but the Lexer is a fair bit more than usual (dedent tokens come to mind; special handling of end of lines as well). I think you need a fair bit of special magic in PetitParser to parse Python. Luckily, Python is well documented in that regard. Thierry

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

Confirmed in even a better way: given how convoluted and hacky is writing a full Python Parser, it is probably not even a Context Free Grammar. Let's agree on the fact that you'll be able to parse it using Context Sensitive Grammar (Type 1) for sure ... and if you're very lucky Context Free (Type 2) might be sufficient but PITA to write and maintain. Agreed? :-)

CU, Udo On 23.09.14 14:20, Thierry Goubier wrote:

2014-09-23 13:57 GMT+02:00 Udo Schneider <udo.schneider@homeaddress.de <mailto:udo.schneider@homeaddress.de>>:

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

Confirmed in even a better way: given how convoluted and hacky is writing a full Python Parser, it is probably not even a Context Free Grammar.

That is: the Python grammar is LALR which is a subset of Context Free Grammar (but already more than a type 3 Chomsky grammar), but the Lexer is a fair bit more than usual (dedent tokens come to mind; special handling of end of lines as well).

I think you need a fair bit of special magic in PetitParser to parse Python.

Luckily, Python is well documented in that regard.

Thierry

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> <mailto: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@__homeaddress.de <mailto:udo.schneider@homeaddress.de>> <mailto:udo.schneider@ <mailto:udo.schneider@>__homead__dress.de <http://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>> <mailto:udo.schneider@ <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de> <mailto:udo.schneider@__homeaddress.de <mailto:udo.schneider@homeaddress.de>>> <mailto:udo.schneider@ <mailto:udo.schneider@> <mailto:udo.schneider@ <mailto:udo.schneider@>>__homea__d__dress.de <http://homead__dress.de> <http://homeaddress.de>

<mailto:udo.schneider@ <mailto:udo.schneider@>__homead__dress.de <http://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>> <mailto:udo.schneider@ <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de> <mailto:udo.schneider@__homeaddress.de <mailto:udo.schneider@homeaddress.de>>> <mailto:udo.schneider@ <mailto:udo.schneider@> <mailto:udo.schneider@ <mailto:udo.schneider@>>__homea__d__dress.de <http://homead__dress.de> <http://homeaddress.de> <mailto:udo.schneider@ <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-________translato... <http://blo____gspot.de/2014/09/block-______translators-parsing-magic.html>

<http://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://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-p... <http://bl__ogspot.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-parsi... <http://blogspot.de/2014/09/block-__translators-parsing-magic.html>

<http://readthesourceluke.__blogspot.de/2014/09/block-__translators-parsing-m... <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

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.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>> 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>>__:

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

Thx for this! I'd say that the material is worthy of inclusion into a bool chapter. Phil Le 23 sept. 2014 12:51, "Udo Schneider" <udo.schneider@homeaddress.de> a écrit :

Phil,

I'd say that's an implementation of the "Material implication"[1] operator from Propositional calculus.

You can write it as

P -> Q

and read it as "P implies Q" or (not 100% correct) "if P (is true) then Q (is true)".

Let's take a look at the truth table:

P | Q | P -> Q ---+---+------- t | t | t ---+---+-------

inserting it into the statement above yields:

"if true then true" which is true indeed.

The funny thing starts when we look at the case(s), where P is false. The general (verbal) rule says that if the premise (P) is false the truth value of the conclusion doesn't matter. Hence the complete term is true:

P | Q | P -> Q ---+---+------- f | t | t ---+---+------- f | f | t ---+---+-------

There is one case left: What happens if the premise is true but the conclusion is false? That's in direct violation of the defintion which states that "if P (is true) then Q (is true)". As P is true and Q is false the truth value of the complete term is false!

P | Q | P -> Q ---+---+------- t | f | f ---+---+-------

Or to put it in different words: An implication can only be false if the premise is true but the conclusion is false.

So we end up with this truth table:

P | Q | P -> Q ---+---+------- t | t | t ---+---+------- f | t | t ---+---+------- f | f | t ---+---+------- t | f | f ---+---+-------

We did not take a look yet, at how to implement this with basic boolean operators. So we need to take a look at the table and find the expression: Let's start with the exception (fourth case). We can express this as:

!(P & !Q) -> "The term is false if P is true and Q is false"

I added the inner term "P & !Q" to the table to make it easier to follow:

P | Q | P -> Q | P & !Q | !(P & !Q) ---+---+--------+--------+----------- t | t | t | f | t ---+---+--------+--------+----------- f | t | t | t | f ---+---+--------+--------+----------- f | f | t | f | t ---+---+--------+--------+----------- t | f | f | f | t ---+---+--------+--------+-----------

The "last" step is to simplify the term "!(P & !Q)" using one of de Morgan's laws: !(A & B) == !A | !B

Using this for our term gives

!(P & !Q) == !P | !!Q == !P | Q

P | Q | P -> Q | P & !Q | !(P & !Q) | !P | Q ---+---+--------+--------+-----------+-------- t | t | t | f | t | t ---+---+--------+--------+-----------+-------- f | t | t | t | f | f ---+---+--------+--------+-----------+-------- f | f | t | f | t | t ---+---+--------+--------+-----------+-------- t | f | f | f | t | t ---+---+--------+--------+-----------+--------

So our final term is "correct" (proof in the truth table) and is equivalent to the smalltalk term:

!P | Q := self not or: [aBlock value]

I have to admit though that implications in Propositional calculus really gave me a headache. You might simply want to accept that they are defined this way. And maybe it doesn't help ... but there are even more strange things lurking around the corner [4] :-)

Although not immidiatly obvious all the terms in Propositional calculus do not neccessarly have a semantic meaning in context to each other. They are totaly independent. The only thing that counts is the truth value of its terms. E.g. something like this is mathematically/syntacically valid but doesn't make any sense from a semantic point of view:

P := I am 12y old Q := It rains

The term "P -> Q" is perfectly fine mathematically/syntacically but doesn't mean anything in terms of semantics.

Hope this helps.

CU,

Udo

[1] http://en.wikipedia.org/wiki/Material_implication_(rule_of_inference) [2] http://en.wikipedia.org/wiki/Propositional_calculus [3] http://en.wikipedia.org/wiki/De_Morgan's_laws [4] http://en.wikipedia.org/wiki/Paradoxes_of_material_implication

On 23.09.14 10:49, phil@highoctane.be wrote:

...

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

Phil, I mixed up the books. It "Fundamentals of Smalltalk Programming Technique, Volume 1" by "Andres Valloud". Just checked it. http://www.lulu.com/shop/andres-valloud/fundamentals-of-smalltalk-programmin... CU, Udo On 23.09.14 16:05, Udo Schneider wrote:

Phil,

If I remember correctly one of Andres Valloud's books has some more information on Boolean (logic) and Smalltalk. I think it was "A Mentoring Course on Smalltalk" [1]. Definitely worth a read!!

CU,

Udo

[1] http://www.lulu.com/shop/andres-valloud/a-mentoring-course-on-smalltalk/pape...

On 23.09.14 13:57, phil@highoctane.be wrote:

...

Thx for this!

I'd say that the material is worthy of inclusion into a bool chapter.

Phil

Le 23 sept. 2014 12:51, "Udo Schneider" <udo.schneider@homeaddress.de <mailto:udo.schneider@homeaddress.de>> a écrit :

Phil,

I'd say that's an implementation of the "Material implication"[1] operator from Propositional calculus.

You can write it as

P -> Q

and read it as "P implies Q" or (not 100% correct) "if P (is true) then Q (is true)".

Let's take a look at the truth table:

P | Q | P -> Q ---+---+------- t | t | t ---+---+-------

inserting it into the statement above yields:

"if true then true" which is true indeed.

The funny thing starts when we look at the case(s), where P is false. The general (verbal) rule says that if the premise (P) is false the truth value of the conclusion doesn't matter. Hence the complete term is true:

P | Q | P -> Q ---+---+------- f | t | t ---+---+------- f | f | t ---+---+-------

There is one case left: What happens if the premise is true but the conclusion is false? That's in direct violation of the defintion which states that "if P (is true) then Q (is true)". As P is true and Q is false the truth value of the complete term is false!

P | Q | P -> Q ---+---+------- t | f | f ---+---+-------

Or to put it in different words: An implication can only be false if the premise is true but the conclusion is false.

So we end up with this truth table:

P | Q | P -> Q ---+---+------- t | t | t ---+---+------- f | t | t ---+---+------- f | f | t ---+---+------- t | f | f ---+---+-------

We did not take a look yet, at how to implement this with basic boolean operators. So we need to take a look at the table and find the expression: Let's start with the exception (fourth case). We can express this as:

!(P & !Q) -> "The term is false if P is true and Q is false"

I added the inner term "P & !Q" to the table to make it easier to follow:

P | Q | P -> Q | P & !Q | !(P & !Q) ---+---+--------+--------+----__------- t | t | t | f | t ---+---+--------+--------+----__------- f | t | t | t | f ---+---+--------+--------+----__------- f | f | t | f | t ---+---+--------+--------+----__------- t | f | f | f | t ---+---+--------+--------+----__-------

The "last" step is to simplify the term "!(P & !Q)" using one of de Morgan's laws: !(A & B) == !A | !B

Using this for our term gives

!(P & !Q) == !P | !!Q == !P | Q

P | Q | P -> Q | P & !Q | !(P & !Q) | !P | Q ---+---+--------+--------+----__-------+-------- t | t | t | f | t | t ---+---+--------+--------+----__-------+-------- f | t | t | t | f | f ---+---+--------+--------+----__-------+-------- f | f | t | f | t | t ---+---+--------+--------+----__-------+-------- t | f | f | f | t | t ---+---+--------+--------+----__-------+--------

So our final term is "correct" (proof in the truth table) and is equivalent to the smalltalk term:

!P | Q := self not or: [aBlock value]

I have to admit though that implications in Propositional calculus really gave me a headache. You might simply want to accept that they are defined this way. And maybe it doesn't help ... but there are even more strange things lurking around the corner [4] :-)

Although not immidiatly obvious all the terms in Propositional calculus do not neccessarly have a semantic meaning in context to each other. They are totaly independent. The only thing that counts is the truth value of its terms. E.g. something like this is mathematically/syntacically valid but doesn't make any sense from a semantic point of view:

P := I am 12y old Q := It rains

The term "P -> Q" is perfectly fine mathematically/syntacically but doesn't mean anything in terms of semantics.

Hope this helps.

CU,

Udo

[1]

http://en.wikipedia.org/wiki/__Material_implication_(rule_of___inference)

<http://en.wikipedia.org/wiki/Material_implication_(rule_of_inference)> [2] http://en.wikipedia.org/wiki/__Propositional_calculus <http://en.wikipedia.org/wiki/Propositional_calculus> [3] http://en.wikipedia.org/wiki/__De_Morgan's_laws <http://en.wikipedia.org/wiki/De_Morgan's_laws> [4] http://en.wikipedia.org/wiki/__Paradoxes_of_material___implication <http://en.wikipedia.org/wiki/Paradoxes_of_material_implication>

On 23.09.14 10:49, phil@highoctane.be <mailto:phil@highoctane.be> wrote:

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

<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-parsi...

<http://blogspot.de/2014/09/block-__translators-parsing-magic.html>

<http://readthesourceluke.__blogspot.de/2014/09/block-__translators-parsing-m...

<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

I reviewed a few techniques for implementing internal / embeddel DSLs in a host language and I didn't saw this one :) IMHO it's a nice tool to know about. Only for specific use cases but still useful.

CU, Udo On 23.09.14 09:06, Thierry Goubier wrote:

Thanks Udo;

I reviewed a few techniques for implementing internal / embeddel DSLs in a host language and I didn't saw this one :)

Thierry

2014-09-23 1:48 GMT+02:00 Udo Schneider <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.__blogspot.de/2014/09/block-__translators-parsing-m... <http://readthesourceluke.blogspot.de/2014/09/block-translators-parsing-magic...>

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

Hi Sven, thanks for the feedback.

Keep that kind of stuff coming, it is very helpful. I'll try to. It just always takes so long to write stuff. But I think you know that, don't you? :-)

CU, Udo On 23.09.14 16:00, Sven Van Caekenberghe wrote:

Hi Udo,

This is really an excellent article: I enjoyed reading it a lot.

It is well written, has lots of relevant code examples and a nice pace, but above all it is really interesting.

Thanks a lot.

Keep that kind of stuff coming, it is very helpful.

Sven

On 23 Sep 2014, at 01:48, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

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

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

Yes I do, but you also know (it was clear from the article) that you learn a lot yourself from writing something for public consumption. Most people underestimate how powerful that is. True indeed - sorting my thoughts to be able to write them down in a coherent way for public consumption really forces me to understand the stuff pretty deeply.

CU, Udo On 23.09.14 21:11, Sven Van Caekenberghe wrote:

On 23 Sep 2014, at 21:00, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

Hi Sven,

thanks for the feedback.

...

Keep that kind of stuff coming, it is very helpful. I'll try to. It just always takes so long to write stuff. But I think you know that, don't you? :-)

Yes I do, but you also know (it was clear from the article) that you learn a lot yourself from writing something for public consumption. Most people underestimate how powerful that is.

...

CU,

Udo

On 23.09.14 16:00, Sven Van Caekenberghe wrote:

...

Hi Udo,

This is really an excellent article: I enjoyed reading it a lot.

It is well written, has lots of relevant code examples and a nice pace, but above all it is really interesting.

Thanks a lot.

Keep that kind of stuff coming, it is very helpful.

Sven

On 23 Sep 2014, at 01:48, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

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

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

Hi udo I agree with sven :) We could easily turn your blog into a chapter for a future book :) I have the impression that the blog is how to avoid parsing and still get translation done! Stef

Hi Sven,

thanks for the feedback.

...

Keep that kind of stuff coming, it is very helpful. I'll try to. It just always takes so long to write stuff. But I think you know that, don't you? :-)

CU,

Udo

On 23.09.14 16:00, Sven Van Caekenberghe wrote:

...

Hi Udo,

This is really an excellent article: I enjoyed reading it a lot.

It is well written, has lots of relevant code examples and a nice pace, but above all it is really interesting.

Thanks a lot.

Keep that kind of stuff coming, it is very helpful.

Sven

On 23 Sep 2014, at 01:48, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

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

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

Hi Udo, On Thu, Sep 25, 2014 at 10:28 PM, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

We could easily turn your blog into a chapter for a future book :) Wow! I didn't really expect that! But I'd happy to help any way I can. Maybe by adding some bits an pieces how to parse blocks with multiple expressions?

I think the most important thing to start with is not to add content, but to put the content you already have in https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english. You will have to use Pillar: https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfu... -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Hi Damien, moving to Pillar was quite easy: http://pillarhub.pharocloud.com/hub/UdoSchneider/6bqsrq7ut85ddotzjy2xqrtth How to proceed? Best Regards, Udo On 29.09.14 18:47, Udo Schneider wrote:

Hi Damien,

I think the most important thing to start with is not to add content,

...

but to put the content you already have in

https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english.

...

You will have to use Pillar:

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfu...

I did write the entry in Markdown - so converting it to Pillar shouldn't be a big deal. I'll start translating t now.

Best Regards,

Udo

On 28.09.2014 11:08, Damien Cassou wrote:

...

Hi Udo,

On Thu, Sep 25, 2014 at 10:28 PM, Udo Schneider <udo.schneider@homeaddress.de> wrote:

...

...

We could easily turn your blog into a chapter for a future book :) Wow! I didn't really expect that! But I'd happy to help any way I can. Maybe by adding some bits an pieces how to parse blocks with multiple expressions?

I think the most important thing to start with is not to add content, but to put the content you already have in https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english. You will have to use Pillar: https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfu...

On 30.09.14 17:50, Damien Cassou wrote:

1- please give me your github username krodelin

2- clone https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english 3- read the README and add your chapter

If you prefer, you can also send a pull request. I'll check the project structure and tell you. But I assume I'd prefer working directly - even if in "my" directory only.

Best Regards, Udo

On 02.10.14 18:17, Damien Cassou wrote:

you should have received an invitation Yepp - I did. Already committed the Blog entry 1:1. Working on cleaning up the language now.

BTW: Is there any guide regarding the kind of language (e.g. tonality) of the book. I'd change the it given the fact that the blog entry is pretty informal which is IMHO not appropriate for a book ... Thanks, Udo

On 06.10.14 11:46, Damien Cassou wrote:

no such guide exist. Do your best and we will do another pass on it afterwards. Ok - good to know. I checked in a version which is IMHO reasonably "clean".

I'll check again in two weeks or so - it's sometimes surprising how different something looks when you didn't take a look at it for a while. CU, Udo