Len is now a FUNCTION and not an operator

BlitzMax Forums/BlitzMax Programming/Len is now a FUNCTION and not an operator

H&K(Posted 2006) [#1]
From Skid 3 mths ago
Len is an operator not a function so the brackets rule does noto apply. The precedense of the . (member access operator) is documented as being higher than the Len operator so my gut feeling is Fabian has found a bug.


http://www.blitzbasic.com/Community/posts.php?topic=62674#701278

from Mark 21/12/2006
You're gonna hate me, but I'm not gonna change this back.

Built-in 'bracketless' functions like this are dumb and I shouldn't have put them in in the first place.

So you have 2 alternatives: use Len(x) or x.length

http://www.blitzbasic.com/Community/posts.php?topic=65895

I have no problem with this. In fact the first time it came up ( http://www.blitzbasic.com/Community/posts.php?topic=62674#701278 ), I would have sworn that it alredy was a function.

But BE AWARE THAT IT IS NOW DEFINATLY A FUNCTION


bregors(Posted 2006) [#2]
.


SculptureOfSoul(Posted 2006) [#3]
Finally. I'm a big fan of regular syntax. Bracketless functions always rubbed me the wrong way (of course, I'm now finding Lisp's syntax to be elegant - so that may say more about me than the issue at hand XD)


Grey Alien(Posted 2006) [#4]
yeah I always got confused about which needed brackets and which didn't or something, so I just put them on everything so you know it's not a field/variable but a method/function.


bregors(Posted 2006) [#5]
.


REDi(Posted 2006) [#6]
They are all brackets ;)

When people say brackets they normaly mean parenthesis ()
[] are called square/box brackets.

*EDIT* http://en.wikipedia.org/wiki/Brackets


Picklesworth(Posted 2006) [#7]
It would be interesting to have a 'code updater' for this sort of stuff.

I made a little script which made the BlitzMax NeHe tutorials work again, so something similar for things like Len shouldn't be too difficult...

My way was really clumsy and stupid, so if anyone feels like it I suggest a scriptable system which identifies functions / variables / arguments and acts on them...
Anyway, just a random thought to toss out there :)


bregors(Posted 2006) [#8]
.


JazzieB(Posted 2006) [#9]
I've never heard of this either, I've always known them as

() - brackets
[] - square brackets
{} - curly brackets
<> - less then / greater than (not even brackets in my book!)

Oh well, you live and learn.


SculptureOfSoul(Posted 2006) [#10]
I was just using Marks terminology - I normally refer to them as parenthesis, but thought that perhaps in the "compiler world" they're referred to as brackets.

M'eh.


EOF(Posted 2006) [#11]
I very much welcome the 'Len(x) or x.length' change.
We need consistency if anything.

My personal preference is to always remove brackets from commands which return nothing. Maybe this came from way back in the earlier days of coding(?)

I always believe COMMANDS/STATEMENTS should not use brackets and FUNCTIONS always have brackets.

This:
DrawText("Huh .. brackets? .. no can do!",10,10)

Verses this:
DrawText "See .. nice and clean!",10,10



SculptureOfSoul(Posted 2006) [#12]
I always believe COMMANDS/STATEMENTS should not use brackets and FUNCTIONS always have brackets.


But, DrawText is a funtion. :)


Azathoth(Posted 2006) [#13]
I think if a function returns a value it should always use brackets, though I also use brackets even if they don't except for print or debuglog.
In Purebasic though I think all functions require brackets.


H&K(Posted 2006) [#14]
I think if a function returns a value it should always use brackets
That was the point tho wasnt it. Was Len a function or unitary operator.
Now I always thought of it as a function, and so always put brackets round what I wanted the LEN of.

However this was wrong, because as pointed out by fabian, and Skid, LEN was/is a Unitary operator, which would mean that it didnt need brackets. Which in fact it doesnt. The problem was in the precedence of LEN, which changed in 1.22 The result of which was that it didnt give the correct/same result.

So to clarify the original post, although LEN is REALLY REALLY a unitary operator, it is going to need Brackets asthough it was a function. Anyone being a smart arse and saying "Well it returned a value so I knew it needed brackets", (Which I did), is just wrong. Does abs need a bracket? No. The brackets are there to ensure that the precedence is kept.

Wish I hadent posted this thread now. And Bregors they are only parenthesis when in text. In listings or maths they are Brackets


Dreamora(Posted 2006) [#15]
so, to make it easy and straight forward, lets just assume: LEN is a function, which does nothing else than return val.length :)


bregors(Posted 2006) [#16]
.


Fabian.(Posted 2006) [#17]
BE AWARE THAT IT IS NOW DEFINATLY A FUNCTION
That's wrong.
LEN is REALLY REALLY a unitary operator
And this of course is right.

Here are three proofs:

1.: You can't find the source code or at least an extern declaration for this "function" (which you can do for all other functions)

2.: You can't find the memory address of the entry point of this "function":
Strict
Framework brl.blitz

Local LenPtr:Byte Ptr = Len
Local LenInt = Int LenPtr
WriteStdout "The Len-function is located at: " + LenInt + "~n"

3.: You don't need brackets at all:
Strict
Framework brl.blitz

WriteStdout Len "123" + 1
WriteStdout "~n"
The only need for brackets is if you're using V1.22/1.24 and want to show the compiler that the expression which is Len's parameter should be compiled before the Len-operator itself. This is because the operator just changed precedence - in V1.20 and before the precedence was lower than the member access operator and higher than the negation operator; in V1.22/1.24 in contrast it has same precedence like the New-operator (which is higher than the member access operator).


Tricky(Posted 2006) [#18]
Honestly I've always used ( and ), thinking that Len was a function. Never looked it up, though.