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, p...@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.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>> wrote:
> just as it is black magic for me now :D
The nice thing about this approach is the fact that it "just"
piggybacks the normal Smalltalk message sending. So you can step
through it using the Debugger - it's Smalltalk all the way down.
I still remember my first shock when (having no formal background on
parsing theory at that time) I saw the parsing tables generated by
T-Gen. Of course it was Smalltalk ... but understanding those tables
was a nightmare.
PetitParser is the gold standard here IMHO. It is able to parse
arbitrary input (compared to my block expressions only). And you can
still use the Debugger to step through the parsing process *and
still understand what's going on!*
CU,
Udo
On 23.09.14 09:54, kilon alios wrote:
just as it is black magic for me now :D
At least I get the general feeling. I am new to parsing too, so
far I
have only played with regex parsing. Not the most smalltalkish
way but
it works well so far.
On Tue, Sep 23, 2014 at 9:39 AM, Udo Schneider
<udo.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>>
wrote:
Hi Estaban,
I think the first time I saw this pattern was in ReStore on
Dolphin
Smalltalk. I didn't understand it's implementation back then. I
assume that it's similar to what I described though. But
having a
Smalltalk block automagically creating the equivalent SQL
SELECT
expression was like black magic at that time :-)
CU,
Udo
On 23.09.14 04:15, Esteban A. Maringolo wrote:
Excellent article.
I think GLORP uses a similar technique to setup its
expressions, and
also have issues with #and:/#or: selectors due to
inlining, so
it uses
AND:/#OR: instead.
Regards!
Esteban A. Maringolo
pd: Your blog and it's choosen topic made me remember
http://use-the-index-luke.com/
2014-09-22 20:48 GMT-03:00 Udo Schneider
<udo.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>>__:
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
