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-programming-technique-volume-1/paperback/product-5299835.html
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/paperback/product-3788890.html
On 23.09.14 13:57, p...@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.schnei...@homeaddress.de
<mailto:udo.schnei...@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, p...@highoctane.be
<mailto: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>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>>
wrote:
> just as it is black magic for me now :D
The nice thing about this approach is the fact that it
"just"
piggybacks the normal Smalltalk message sending. So you can
step
through it using the Debugger - it's Smalltalk all the way
down.
I still remember my first shock when (having no formal
background on
parsing theory at that time) I saw the parsing tables
generated by
T-Gen. Of course it was Smalltalk ... but understanding
those tables
was a nightmare.
PetitParser is the gold standard here IMHO. It is able to
parse
arbitrary input (compared to my block expressions only).
And you can
still use the Debugger to step through the parsing
process *and
still understand what's going on!*
CU,
Udo
On 23.09.14 09:54, kilon alios wrote:
just as it is black magic for me now :D
At least I get the general feeling. I am new to parsing
too, so
far I
have only played with regex parsing. Not the most
smalltalkish
way but
it works well so far.
On Tue, Sep 23, 2014 at 9:39 AM, Udo Schneider
<udo.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>
<mailto:udo.schneider@
<mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>>>
wrote:
Hi Estaban,
I think the first time I saw this pattern was in
ReStore on
Dolphin
Smalltalk. I didn't understand it's implementation
back then. I
assume that it's similar to what I described
though. But
having a
Smalltalk block automagically creating the
equivalent SQL
SELECT
expression was like black magic at that time :-)
CU,
Udo
On 23.09.14 04:15, Esteban A. Maringolo wrote:
Excellent article.
I think GLORP uses a similar technique to
setup its
expressions, and
also have issues with #and:/#or: selectors
due to
inlining, so
it uses
AND:/#OR: instead.
Regards!
Esteban A. Maringolo
pd: Your blog and it's choosen topic made me
remember
http://use-the-index-luke.com/
2014-09-22 20:48 GMT-03:00 Udo Schneider
<udo.schnei...@homeaddress.de
<mailto:udo.schnei...@homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>
<mailto:udo.schneider@
<mailto:udo.schneider@>__homead__dress.de <http://homeaddress.de>
<mailto:udo.schneider@__homeaddress.de
<mailto:udo.schnei...@homeaddress.de>>>>__:
All,
I just finished a blog entry. It shows how
to use
Smalltalk
blocks as parsers/translators. E.g.
translating a Block
[:customer | (customer joinDate
year is: Date
today year)]
into an SQL-like String
(YEAR(customers.joinDate) = 2014)
The SQL stuff is just an example - you can
create
nearly any
output.
Check out
http://readthesourceluke.__blo____gspot.de/2014/09/block-______translators-parsing-magic.html
<http://blo__gspot.de/2014/09/block-____translators-parsing-magic.html>
<http://blogspot.de/2014/09/__block-__translators-parsing-__magic.html
<http://blogspot.de/2014/09/block-__translators-parsing-magic.html>>
<http://readthesourceluke.__bl__ogspot.de/2014/09/block-____translators-parsing-magic.html
<http://blogspot.de/2014/09/block-__translators-parsing-magic.html>
<http://readthesourceluke.__blogspot.de/2014/09/block-__translators-parsing-magic.html
<http://readthesourceluke.blogspot.de/2014/09/block-translators-parsing-magic.html>__>__>
Maybe that's old stuff for some of you -
but I hope
it's
interesting for some at least :-)
Comments and feedback appreciated.
CU,
Udo
