BLOG: Block Translators - parsing magic

>
>
> 2014-09-23 13:57 GMT+02:00 Udo Schneider <[hidden email]
> <mailto:[hidden email]>>:
>
>     > 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
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>         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
>                  <[hidden email]
>         <mailto:[hidden email]>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                  <mailto:udo.schneider@
>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>                  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
>
>           <[hidden email]
>         <mailto:[hidden email]>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                           <mailto:udo.schneider@
>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                           <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:[hidden email]
>         <mailto:[hidden email]>>>>>
>                           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
>
>         <[hidden email]
>         <mailto:[hidden email]>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                           <mailto:udo.schneider@
>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>                                    <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:[hidden email]
>         <mailto:[hidden email]>>>>>__:
>
>
>                                        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://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-parsing-magic.html
>         <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-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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> 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
>
> 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" <[hidden email]
> <mailto:[hidden email]>> 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, [hidden email]
>     <mailto:[hidden email]> 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
>         <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>         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
>                  <[hidden email]
>         <mailto:[hidden email]>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                  <mailto:udo.schneider@
>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>>>
>                  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
>                           <[hidden email]
>         <mailto:[hidden email]>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>
>                           <mailto:udo.schneider@
>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>                  <mailto:[hidden email]
>         <mailto:[hidden email]>>>>__:
>
>
>                               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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> 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
> <[hidden email]
> <mailto:[hidden email]>>:
>
>     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
>
>
>

> 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 <[hidden email]> 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.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
>>
>>
>
>
>

> 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 <[hidden email]> 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.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
>>>
>>>
>>
>>
>>
>
>
>

>
> On 23 Sep 2014, at 21:00, Udo Schneider <[hidden email]> 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 <[hidden email]> 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.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,
>
> 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/paperback/product-3788890.html
>
>
>
> On 23.09.14 13:57, [hidden email] 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"
>> <[hidden email]
>> <mailto:[hidden email]>> 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, [hidden email]
>>     <mailto:[hidden email]> 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
>>         <[hidden email]
>>         <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>>
>>         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
>>                  <[hidden email]
>>         <mailto:[hidden email]>
>>                  <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>                  <mailto:udo.schneider@
>>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>>                  <mailto:[hidden email]
>>         <mailto:[hidden email]>>>>
>>                  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
>>
>> <[hidden email]
>>         <mailto:[hidden email]>
>>                  <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>                           <mailto:udo.schneider@
>>         <mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
>>                  <mailto:[hidden email]
>>
>> <mailto:[hidden email]>>>>__:
>>
>>
>>                               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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>

> 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
>> <[hidden email]> 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.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
>>>
>>>
>>
>>
>>
>
>
>
>

> 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
>>> <[hidden email]> 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.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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

> Hi Udo,
>
> On Thu, Sep 25, 2014 at 10:28 PM, Udo Schneider
> <[hidden email]> 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/lastSuccessfulBuild/artifact/PillarChap/Pillar.pillar.pdf
>

> 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/lastSuccessfulBuild/artifact/PillarChap/Pillar.pillar.pdf
>
> 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
>> <[hidden email]> 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/lastSuccessfulBuild/artifact/PillarChap/Pillar.pillar.pdf
>>
>>
>
>
>
>