AutoIT Language: Why BitAND is not an infix statement

[Robinson1]

Okay it's about the style of the AutoIT Language. Concerning: 
BitAND, BitOR, BitXOR, BitXOR, 
BitShift, BitRotate
That's a very simple but fundamental question:
 Why BitAND is not  infix?

In most other common programming languages it is.
Let's take JavaScript. Here I write:

Result = Value & Mask

But on AutoIT it's

$Result = BitAND ( $Value , $Mask )

That's more the Lisp / prefix way.
While the logical and is indeed infix
 

$bIsEnable = $bIsGUI_chkEnabled and $bIsGUI_chkChecked

So I wonder why it is like this.
What is the Idea behind this language design decision?  

Okay Autoit is a matured Language but yeah -  It's never to late for a change.
Wasn't there ideas to unify it any way?
So we also make the 'Bit' operations infix as well?
... while Just keeping the 'old' prefix version -for backwards compatibility - as well.

UPDATE #1: Now I created a ticket for this:
https://autoitscript.com/trac/autoit/ticket/3752

Well to generalise/modulate It more I may bring it down to the Subject Verb Object  thing you have with language.
"I go swimming" that's S-V-O or some infix.
"Swimming I go". is O-S-V - postfix and sound much like yoda-style. While
"go I swimming" is V-S-O - prefix and 'feels' more like kinda question.

There is no right or wrong here - however personally I find infix is most appropriate here.

Edited April 8, 2020 by Robinson1

[Nine]

Each language has its idiosyncrasies.  The form is less important than the result.  As long as we have the method to perform the task, I don't care how it is done.  I have learned so many programming languages over the years, that it is not bothering to use one way or the other.  What you are asking is kind of puerile.  In my opinion, you are implying that everybody should speak english, because it would be nice to be all identical.  It doesn't work that way.

[Robinson1]

Cool thanks for your reply.

6 minutes ago, Nine said:

The form is less important than the result.  As long as we have the method to perform the task, I don't care how it is done. 

Fully go ya point. The pragmatic programmer. No matter how it's done - as long as it is done.

However I see coding and code as kinda of art.
So it that context such puerile questions matters.

[Jos]

It is what it is.  

 

[jchd]

It's because AutoIt results from an incremental (spiral-type) development for interactive automation, not as a full-fledged language.

Your remark applies to Mod() as well, something we all can live with quietly.

I see you feel it matters, so you'd be more than happy with a complete functional language like Wolfram Mathematica.

[Robinson1]

10 hours ago, jchd said:

Your remark applies to Mod() as well

Good point. Mod() is good candidate for a mod and a POC.  
Nice to have some challenges. Doing MATE gave me some good inside and idea how AutoIt works - I guess just for fun I may create some MODed AutoIT that'll accept
 

$result = mod(3,2) 

as well as 

$result = 3 mod 2

Token opcodes  0x40 .. 0x58 are in used for operators.
0x59 .. 0x7E are still *free* to use.
So I may use 0x60 for the new  infix mod operator

Edited April 7, 2020 by Robinson1

[argumentum]

Do keep in mind that @jchd said about how this automation tool evolved.
In any case, there is a ticket system where you can make a request @Robinson1.
Everything is kept as backwards compatible as possible in v3 ( there was a v2 ).
But who knows, maybe it gets implemented if is not a big deal.

[Robinson1]

@argumentum
Oh well I should have done this in first place - Well now I did:

...
UPDATE #1: Now I created a ticket for this:
https://autoitscript.com/trac/autoit/ticket/3752
...
Let's see what happens.

[jchd]

Stay home but don't hold your breath.

[markyrocks]

Im not privy to the specifics but it just has to do with the way autoit was written as been said before.  The best guess would be how autoit handles various variables and how it guesses what exactly the expected outcome is supposed to be.

The & symbol is used when combining strings so the language assumes that the variables in question are strings. Doing simple tests will help you understand this better.

$a=1+2

MsgBox('','',$a & VarGetType($a))   ;this results in a 3 and type int32

$a=$a & 3

MsgBox('','',$a & VarGetType($a)) ;this results in a 33 and type string

the point is if you use some type of operation that results in binary if you try to bitand() said binary  using & it will just be a string and not be interpreted correctly further on down the line if its being fed into a function thats expecting raw bytes but gets a string instead.  That string will be converted into the binary representation of the ascii characters that were sent or the function will fail entirely either way the result is not going to be the expected outcome.

you also have to think of these keywords and operators as functions.  Using the keyword "and" really is the equivalent to

$x= $y and $z

;gets interpreted in my imagination as something like

$x=and($y,$z)

;which is defined somewhere else probably lala land...

bool and(auto arg1,auto arg2)
{
    if ((arg1 == true) && (arg2 == true))
        {return true
        }
    else
        {return false
        }

}

you start to understand why this all becomes necessary.  I guess its possible to have multiple functions named and() but they'd have to be in separate namespaces and then the issue becomes short of specifying variable types or return types how does the interpreter decide what to do with what is being sent to it? If that becomes necessary then its starting to flush the simplicity aspect of the language down the drain.  

don't ask me why mod() exists vs % symbol. apparently % doesn't exist. 

That all being said using bitand() = & once it goes through the compiler.  If you really want to start asking some serious questions you should probably be asking why we arn't just coding in machine code.  bc afterall we could just eliminate all this business and just type it out in 1s an 0s.