The Inbox: Kernel-fn.1151.mcz

> On 09.02.2018, at 19:06, Fabio Niephaus <[hidden email]> wrote:
>
> On Fri, Feb 9, 2018 at 6:31 PM Chris Cunningham <[hidden email]> wrote:
> #xor: is on the same plane as #| and #& - evaluate both sides and apply
>
> We also have #and: and #or: - evaluate receiver, and evaluate argument block if and only if necessary.
>
> I use #and: and #or: for speed purposes - and to avoid side effects (sometimes).
>
> I'm just curious - is there an equivalent symbol for xor similar to | and & that we could use?
>
> In some languages, they use ^ but for obvious reason that's not useful. I wonder if we could use ~ for #xor:?

Wikipedia says:

"It is symbolized by the prefix operator J[2] and by the infix operators XOR (/ˌɛks ˈɔːr/), EOR, EXOR, ⊻, ⩒, ⩛, ⊕, ↮, and ≢. "

Theoretically, we could use any of these symbols, (⊕ is often used in maths) but our fonts don't display them yet, so that has to wait.

Further there:

        "+, a plus sign", well, would work (on booleans) but could be confusing
        "J, as in Jpq", not working for us

        ", sometimes written as
        • ><
        • >-<"

        THAT could work.

I like

        a >< b

it looks like an X a bit.

Best regards
        -Tobias

PS: GMail/Inbox apparently destroys the citation level :(

>
>
> Also, before making this change to using blocks (if we do), we'd need to fix all users - probably also in the VMMaker packages.
>
> Right...fortunately, there aren't that many senders...
>
> Fabio
>
>
> -cbc
>
> On Fri, Feb 9, 2018 at 9:18 AM, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 9 Feb 2018, marcel.taeumel wrote:
>
> commits-2 wrote
> A new version of Kernel was added to project The Inbox:
> http://source.squeak.org/inbox/Kernel-fn.1151.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-fn.1151
> Author: fn
> Time: 9 February 2018, 12:32:25.516883 pm
> UUID: 9fb7df4b-6bf4-4af8-9c75-7496c2f0b517
> Ancestors: Kernel-tonyg.1150
>
> For consistency: allow blocks to be passed into #xor: (see #or: and
> #and:).
>
> =============== Diff against Kernel-tonyg.1150 ===============
>
> Item was changed:
>  ----- Method: False>>xor: (in category 'logical operations') -----
> + xor: alternativeBlock
> - xor: aBoolean
>        "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>
> +       ^alternativeBlock value!
> -       ^aBoolean!
>
> Item was changed:
>  ----- Method: True>>xor: (in category 'logical operations') -----
> + xor: alternativeBlock
> - xor: aBoolean
>        "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>
> +       ^alternativeBlock value not!
> -       ^aBoolean not!
>
> Hey Nicolas,
>
> it seems that you had the intention to not allow "a xor: [b]" because,
> obviously, one does always have to check both operands for XOR. Yet, would
> it do any harm if we would allow "a xor: [b]"?
>
> Performance. Two fold: you create a block for no reason, because it will always be evaluated right after its creation.
> If there is no block, #value still has to be sent.
>
> Levente
>
>
>
> Best,
> Marcel
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>
>
>

On 02/09/2018 06:47 PM, Nicolas Cellier wrote:
> We also have a pair of binary messages that already works: ~= or even ~~

This is actually an excellent point.

Perhaps the extra inefficiencies from the proposed new xor: definition
that Levente identified are acceptable, given that performance-critical
code can just use ~= or ~~?

Being able to accept "a xor: b" as well as "a xor: [b]" seems like a win
for consistency with the other spelled-out operators to me.

> On 10.02.2018, at 20:36, Tony Garnock-Jones <[hidden email]> wrote:
>
> On 02/10/2018 07:02 PM, Levente Uzonyi wrote:
>> So,
>>    a perform: {#or:. #xor:. #and:} atRandom with: b
>> would just work for that imaginary interpreter if b were a Boolean.
>
> Yes, that "interpreter" works just fine today, if b is a Boolean. It's
> the case where b is a Boolean-producing expression - such as in a "lazy"
> interpreter - that doesn't work without Fabio's proposed change.
>
> I went and looked at the ANSI standard (draft), btw [1].
>
> There, #xor: is specified as taking only a boolean.
>
> So this would be an extension, potentially affecting portability, for
> what that's worth these days.
>
> I think the performance objection has been well-refuted, and I see the
> consistency benefit as being real, but probably pretty limited, and I
> kind of don't like the potential portability implications.

I presume the main "feeling" here is parallelity:

#& takes an evaluated boolean   #and: takes an unevaluated block
#| takes an evaluated boolean   #or: takes an unevaluated block

#xor: takes an evaluated boolean but looks like #and: and #or:,
So it seems to belong to the right side, and then we think again about
the left side, come up with symbols, only to find that #~= and #~~ are already there.

So, just lets go all the way and document #xor: better, not making take it a block,
maybe pointing out that #~= ist typically better fitted…

Best regards
        -Tobias