[Proposal] ## operator

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tony Papadimitriou
Ah, so the problem is that IN is not an operator (as if it matters how you
want to look at it), and not how IN can be used to make programming
expression easier?

Generic 'for'?  Not so generic, I guess.

-----Original Message-----
From: Dirk Laurie
Sent: Friday, November 21, 2014 9:46 PM

> (Another thing that I would expect is the IN operator to work like in
> Python
> when used with strings.  But that’s another discussion...)

`in` is not an operator any more than `end` is. It is a token in the syntax
of the generic `for`.


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Tim Hill
In reply to this post by Axel Kittenberger

> On Nov 21, 2014, at 9:02 AM, Axel Kittenberger <[hidden email]> wrote:
>
> You're knowledge about other peoples fields and the issues they are regulary facing?
>
> Anyway, I agree such operator is not a good idea, simply because the count isn't stored in the core. If it would, I'd say instead by all means make that integer accessible to the script, no big harm.
>
> However, the resoning ought to be, what is a strong concept and well doable with the current code base without bloating it? In this case it is not.
>
> Not, "I don't need that in my field of work, so I just suppose other don't as well." Or do you have a scientific method on operationalising how often other people need this or that with their way of using Lua?
>

From previous discussions the argument goes (I think) like this: The table implementation does NOT currently store the number of keys. Modifying it to do so is of course possible, but it’s a little more complex than might at first appear (you have to handle things like placing a nil in the “array" part or over-writing a nil in the array part for example).

Such code in the table implementation, even with all the wrinkles, would undoubtedly be faster than anything that can be coded in Lua by a wide margin. HOWEVER, this code overhead is incurred for EVERY table in EVERY program all the time. When viewed this way, any savings you make for the very occasional instance when you need the key count of a table is overwhelmed by the overhead of doing all those useless counts on all the other tables; even by programs that NEVER get a key count anywhere.

This, as I understand it, is also the rationale behind the current # operator for tables; the operator itself is (relatively) slow since it computes array size on a just-in-time basis, but this slowness is preferable to always tracking the sequence size pro-actively since in many cases this information is never needed.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tim Hill
In reply to this post by Tony Papadimitriou

On Nov 21, 2014, at 11:37 AM, [hidden email] wrote:

Well, # is the length operator and it’s meant to return the length of whatever follows, provided what follows has a concept of length/size (e.g., table, string), so one -- I being that one, I guess :) -- would expect if a number follows it would return its length (of its common printable representation), rather than give error.  In other words, I would expect to #number to be equivalent to #(#number..’’)
In any case, in a ‘loosely typed language’ giving an error when there is a non-error alternative behavior does not serve any useful purpose, does it?
 
Obviously, it’s not a big issue as it’s easy to overcome, but it seems (to me, at least) not the best possible behavior for #number

It’s pretty much agreed that the automatic coercion between strings and numbers in Lua is not good, and is usually discouraged (and there have been discussions about deprecating it). And one of the reasons it’s not good is the very example you give. The “..” operator is non-polymorphic; it always operates on strings[1], so there is no ambiguity as to the desired type of the operator arguments. The “#” operator is polymorphic, and so type coercion is far more ambiguous (and therefore should be avoided). And if you REALLY need # on numbers then it can be added via the C API by adding a metatable to the number type.

—Tim

[1] Ignoring metatables, that is.
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Soni "They/Them" L.
In reply to this post by Tim Hill

On 21/11/14 07:01 PM, Tim Hill wrote:

>> On Nov 21, 2014, at 9:02 AM, Axel Kittenberger <[hidden email]> wrote:
>>
>> You're knowledge about other peoples fields and the issues they are regulary facing?
>>
>> Anyway, I agree such operator is not a good idea, simply because the count isn't stored in the core. If it would, I'd say instead by all means make that integer accessible to the script, no big harm.
>>
>> However, the resoning ought to be, what is a strong concept and well doable with the current code base without bloating it? In this case it is not.
>>
>> Not, "I don't need that in my field of work, so I just suppose other don't as well." Or do you have a scientific method on operationalising how often other people need this or that with their way of using Lua?
>>
>  From previous discussions the argument goes (I think) like this: The table implementation does NOT currently store the number of keys. Modifying it to do so is of course possible, but it’s a little more complex than might at first appear (you have to handle things like placing a nil in the “array" part or over-writing a nil in the array part for example).
>
> Such code in the table implementation, even with all the wrinkles, would undoubtedly be faster than anything that can be coded in Lua by a wide margin. HOWEVER, this code overhead is incurred for EVERY table in EVERY program all the time. When viewed this way, any savings you make for the very occasional instance when you need the key count of a table is overwhelmed by the overhead of doing all those useless counts on all the other tables; even by programs that NEVER get a key count anywhere.
>
> This, as I understand it, is also the rationale behind the current # operator for tables; the operator itself is (relatively) slow since it computes array size on a just-in-time basis, but this slowness is preferable to always tracking the sequence size pro-actively since in many cases this information is never needed.
>
> —Tim
>
>
Somehow Java gets away with it...

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Axel Kittenberger
In reply to this post by Tim Hill
From previous discussions the argument goes (I think) like this.

Which is basically what I said, didn't I? In case you need a counter for a specific object just keep count with a proxy metatable for said object. Again a implementation in Lua would do nothing magically different than a native C would do.
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tony Papadimitriou
In reply to this post by Tim Hill
Thank you for your comments.
 
Regarding automatic coercion between strings and numbers being a bad (‘not good’) thing, I’d certainly be in the minority group then, among those who strongly disagree with this, and for me this is just one of the many reasons to like Lua.
 
My reasoning is this:
 
From a human point of view numbers are (have always been) nothing more than strings of digits, just like words are strings of letters.  Think how you write them on paper, or when you type.
Only for computing convenience (based on today’s technologies) we have made a ‘special arrangement’ for numbers to be treated differently internally.  But, in an ideal world, a computing language should hide whatever machine requirements from the user as much as possible/feasible.  There is nothing wrong with thinking of numbers as strings that just *happen* to contain mostly digits.  So, in my view deprecating this ‘bad thing’ would be an utter mistake.  Lua is already in the right direction to the ideal, why go back?
It’s pretty much agreed that the automatic coercion between strings and numbers in Lua is not good, and is usually discouraged (and there have been discussions about deprecating it). And one of the reasons it’s not good is the very example you give. The “..” operator is non-polymorphic; it always operates on strings[1], so there is no ambiguity as to the desired type of the operator arguments. The “#” operator is polymorphic, and so type coercion is far more ambiguous (and therefore should be avoided). And if you REALLY need # on numbers then it can be added via the C API by adding a metatable to the number type.
—Tim
[1] Ignoring metatables, that is.
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Andrew Starks


On Saturday, November 22, 2014, <[hidden email]> wrote:
Thank you for your comments.
 
Regarding automatic coercion between strings and numbers being a bad (‘not good’) thing, I’d certainly be in the minority group then, among those who strongly disagree with this, and for me this is just one of the many reasons to like Lua.
 
My reasoning is this:
 
From a human point of view numbers are (have always been) nothing more than strings of digits, just like words are strings of letters.  Think how you write them on paper, or when you type.
Only for computing convenience (based on today’s technologies) we have made a ‘special arrangement’ for numbers to be treated differently internally.  But, in an ideal world, a computing language should hide whatever machine requirements from the user as much as possible/feasible.  There is nothing wrong with thinking of numbers as strings that just *happen* to contain mostly digits.  So, in my view deprecating this ‘bad thing’ would be an utter mistake.  Lua is already in the right direction to the ideal, why go back?

This topic has a high likelihood of wearing many people out, and since you asked and it's your thread:

I believe that you're saying that when someone reads a string of numbers, they immediately think of that string as a number, not a string with number values. For that matter, any value that is pretty printed is a candidate for that. I get that it's not the same and this does not serve to argue against your point, but "false" might also then evaluate to `false`, and it's certainly why some languages consider "" as such. 

Between me and the fine people that make Lua are many obstacles to perfect understanding. On top of that, computers are pretty stupid and so it is a reasonable approach to make each layer of abstraction simple and the rules that govern them clear and devoid of too many exceptions. 

Altleast that's why I generally prefer that coercion are explicit. I'll take an error over a tricky bug that pops up 2 months later and only on a small number of systems, any day. The later is more likely when the language "helps me out" without me telling it to do so. 

-Andrew

 
From: <a title="drtimhill@gmail.com" href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;drtimhill@gmail.com&#39;);" target="_blank">Tim Hill
It’s pretty much agreed that the automatic coercion between strings and numbers in Lua is not good, and is usually discouraged (and there have been discussions about deprecating it). And one of the reasons it’s not good is the very example you give. The “..” operator is non-polymorphic; it always operates on strings[1], so there is no ambiguity as to the desired type of the operator arguments. The “#” operator is polymorphic, and so type coercion is far more ambiguous (and therefore should be avoided). And if you REALLY need # on numbers then it can be added via the C API by adding a metatable to the number type.
—Tim
[1] Ignoring metatables, that is.
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Tom N Harris
In reply to this post by Soni "They/Them" L.
On Friday, November 21, 2014 07:27:12 PM Thiago L. wrote:
> Somehow Java gets away with it...

Java does not have tables or anything like it. Only POD types and simple
arrays. Everything else is built on top of the VM as classes.

So what you're really saying is if you want to track the number of items in a
table, the best way is to code your own item-counting class using metamethods.
And I agree.

Java is also much larger than Lua.

--
tom <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Soni "They/Them" L.

On 22/11/14 10:04 PM, Tom N Harris wrote:
> On Friday, November 21, 2014 07:27:12 PM Thiago L. wrote:
>> Somehow Java gets away with it...
> Java does not have tables or anything like it. Only POD types and simple
> arrays. Everything else is built on top of the VM as classes.
>
> So what you're really saying is if you want to track the number of items in a
> table, the best way is to code your own item-counting class using metamethods.
Doesn't solve the problem for arbitrary input.
> And I agree.
>
> Java is also much larger than Lua.
>

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Tim Hill
In reply to this post by Axel Kittenberger

On Nov 21, 2014, at 1:40 PM, Axel Kittenberger <[hidden email]> wrote:

From previous discussions the argument goes (I think) like this.

Which is basically what I said, didn't I? In case you need a counter for a specific object just keep count with a proxy metatable for said object. Again a implementation in Lua would do nothing magically different than a native C would do.

Sure, I wasn’t disagreeing with you, just expanding for the OP.

—Tim

Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Axel Kittenberger
In reply to this post by Tony Papadimitriou
From a human point of view numbers are (have always been) nothing more than strings of digits.

Since you said "always",  it certainly was not always a string of decimal digits. There were 12 and 60 based systems, for those people felt more natural. The romans had their unique name to see numbers as strings of letters. For a roman the length of #IX would be II. Substract one and the length of #VIII would be III. More.

And to go back to decimal system, this reasoning gets very problematic when entering non integer rational numbers. So the length #(10/3) would be infinite? Or Fifty-something depending on the floating point arithmetic implementation of the current processor?

PS: For computers a number is just a fixed size string of binary digits. With a floating decimal point and some encodings in case of floating points.

Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tony Papadimitriou
You’re almost right!  But, I avoided to use the word decimal, I only used the word digit.
 
(BTW ‘always’ was in reference to ‘writing’ so I hope no one else will pop up saying that before that there was no concept of writing, and before that, no concept of numbers.)
 
Although your intent was a bit different, in fact you’re helping my case become clearer.
 
A hexadecimal number is made up of digits 0 through 9, and A through F.  We call them collectively hex digits, don’t we?  We do not call 0-9 hex digits, and A-F hex letters.  (Although I wouldn’t be surprised if some did.)
 
The same with Roman numerals, or even the ancient Greek numbering system (this was decimal BTW), which borrowed digits from the alphabet (until the so called ‘Arabic’ system became the norm).
 
But these ‘alphabetic numeral’ strings that (obviously) denoted numbers were pronounced as numbers, not as the sounds of the letters that composed them.  Even to this day, the ancient Greek numbering system survives to some extent, and with the exception of ‘illiterates’, they are pronounced as numbers.  For example, IB’ is pronounced 12th, not ‘iv’.
 
Regarding the length of a number being different depending on what numbering system is used, this is correct and expected behavior.  Would you want the length of hex ABCD to be anything other than four? Or, the equivalent decimal 43981’s length to be anything other than five?  I don’t think so.
 
To help you understand my point better, think of a very simple and common application.  If you want to center a number within some fixed length (say a terminal screen of fixed width), you need the length of the number (in whatever representation that number is to be shown) so you can subtract it from the total available length, and add half that number of spaces to the front of the string to center it.  Simple?
 
Regarding the length of irrational numbers (e.g., 1/3) this is obviously the same as the length of its representation. Now, if you intent to print the infinite series of numbers then I guess in that case its length would be infinity.  But, do you?
 
Why do you have to have an absolute number as the length of any given number?  The length is relevant to the representation.  A binary ten is four digits long (1010), a decimal ten is two digits long (10), and a hex ten is one digit long (A).
 
But isn’t the same true for language words?  Any word’s length is based on its representation in a given language, or even in the same language with multiple valid spellings.  In English, for example, some say potatoe, some say potato (regardless of which form you consider correct, that’s irrelevant.)  Same length?
 
Obviously, for decimal numbers (rational or irrational) the length has to include the decimal point.  It also has to include a possible sign (even if that sign is an explicit +, but obviously not an implicit +).
 
In simple terms, the length of a number is how that number would be represented if you were to print it out.  No complicated rules.  No super science.  If I can convert the number to a string and get its length, then that’s the number I’m looking for.
 
Thanks.
Sent: Sunday, November 23, 2014 2:03 PM
Subject: Re: ## operator (error)
 
From a human point of view numbers are (have always been) nothing more than strings of digits.
 
Since you said "always",  it certainly was not always a string of decimal digits. There were 12 and 60 based systems, for those people felt more natural. The romans had their unique name to see numbers as strings of letters. For a roman the length of #IX would be II. Substract one and the length of #VIII would be III. More.
 
And to go back to decimal system, this reasoning gets very problematic when entering non integer rational numbers. So the length #(10/3) would be infinite? Or Fifty-something depending on the floating point arithmetic implementation of the current processor?
 
PS: For computers a number is just a fixed size string of binary digits. With a floating decimal point and some encodings in case of floating points.
 
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Andrew Starks


On Sunday, November 23, 2014, <[hidden email]> wrote:
You’re almost right!  But, I avoided to use the word decimal, I only used the word digit.
 
(BTW ‘always’ was in reference to ‘writing’ so I hope no one else will pop up saying that before that there was no concept of writing, and before that, no concept of numbers.)
 
Although your intent was a bit different, in fact you’re helping my case become clearer.
 
A hexadecimal number is made up of digits 0 through 9, and A through F.  We call them collectively hex digits, don’t we?  We do not call 0-9 hex digits, and A-F hex letters.  (Although I wouldn’t be surprised if some did.)
 
The same with Roman numerals, or even the ancient Greek numbering system (this was decimal BTW), which borrowed digits from the alphabet (until the so called ‘Arabic’ system became the norm).
 
But these ‘alphabetic numeral’ strings that (obviously) denoted numbers were pronounced as numbers, not as the sounds of the letters that composed them.  Even to this day, the ancient Greek numbering system survives to some extent, and with the exception of ‘illiterates’, they are pronounced as numbers.  For example, IB’ is pronounced 12th, not ‘iv’.
 
Regarding the length of a number being different depending on what numbering system is used, this is correct and expected behavior.  Would you want the length of hex ABCD to be anything other than four? Or, the equivalent decimal 43981’s length to be anything other than five?  I don’t think so.
 
To help you understand my point better, think of a very simple and common application.  If you want to center a number within some fixed length (say a terminal screen of fixed width), you need the length of the number (in whatever representation that number is to be shown) so you can subtract it from the total available length, and add half that number of spaces to the front of the string to center it.  Simple?
 
Regarding the length of irrational numbers (e.g., 1/3) this is obviously the same as the length of its representation. Now, if you intent to print the infinite series of numbers then I guess in that case its length would be infinity.  But, do you?
 
Why do you have to have an absolute number as the length of any given number?  The length is relevant to the representation.  A binary ten is four digits long (1010), a decimal ten is two digits long (10), and a hex ten is one digit long (A).
 
But isn’t the same true for language words?  Any word’s length is based on its representation in a given language, or even in the same language with multiple valid spellings.  In English, for example, some say potatoe, some say potato (regardless of which form you consider correct, that’s irrelevant.)  Same length?
 
Obviously, for decimal numbers (rational or irrational) the length has to include the decimal point.  It also has to include a possible sign (even if that sign is an explicit +, but obviously not an implicit +).
 
In simple terms, the length of a number is how that number would be represented if you were to print it out.  No complicated rules.  No super science.  If I can convert the number to a string and get its length, then that’s the number I’m looking for.

And that's the sentence that captures the other argument, so long as you emphasize "you."

For example, it would be completey reasonable for someone else to expect and hope that the result is "INF".  This sentinel value is available in the language and that is the length of the number, in decimal. Why should I accept the ambiguous answer of 13 (or whatever) when INF is both available as an answer and known to be the correct answer, in real life. 

Even if the above is "wrong" (other than my math or whether or not a computer really can know if a number is irrational), it can only be called such, because your context demands it, whether it be computer science or engineering or horse sense. That is, it is belief and not truth, which is a weaker construct. 

By requiring that the artist (aka programmer) express her intent, they:

1: spell out in code what they expected to see. 

2: can easily discover and correct any problems in code that is causing that expectation to be unfulfilled. 

If you believe in programmer joy and that joy is lessened when they are admoshed with error messages that are solved by otherwise avoidable bits of book keeping code AND you have faith that the details of this abstraction are widely agreed upon, then I can see how your POV is valid. 

-Andrew
 
Thanks.
From: <a title="axkibe@gmail.com" href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;axkibe@gmail.com&#39;);" target="_blank">Axel Kittenberger
Sent: Sunday, November 23, 2014 2:03 PM
To: <a title="lua-l@lists.lua.org" href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;lua-l@lists.lua.org&#39;);" target="_blank">Lua mailing list
Subject: Re: ## operator (error)
 
From a human point of view numbers are (have always been) nothing more than strings of digits.
 
Since you said "always",  it certainly was not always a string of decimal digits. There were 12 and 60 based systems, for those people felt more natural. The romans had their unique name to see numbers as strings of letters. For a roman the length of #IX would be II. Substract one and the length of #VIII would be III. More.
 
And to go back to decimal system, this reasoning gets very problematic when entering non integer rational numbers. So the length #(10/3) would be infinite? Or Fifty-something depending on the floating point arithmetic implementation of the current processor?
 
PS: For computers a number is just a fixed size string of binary digits. With a floating decimal point and some encodings in case of floating points.
 
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Philipp Janda
In reply to this post by Tony Papadimitriou
Am 23.11.2014 um 19:32 schröbte [hidden email]:
>
> Regarding the length of a number being different depending on what
> numbering system is used, this is correct and expected behavior.
> Would you want the length of hex ABCD to be anything other than four?

You seem to. `#tostring(0xABCD)` (or in case you have `__len` for
numbers like you propose: `#0xABCD`) is neither four nor six.
Same problem for `#"1E9"` vs. `#1E9`, so this would be a case where you
cannot use numbers and numeric strings interchangeably.

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Roberto Ierusalimschy
It is funny (and a little sad) that, with all this disussion about the
length of numbers, nobody noticed that 5.3-beta has a bug there:

Lua 5.3.beta  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> x = 3
> #x
stdin:1: attempt to get length of a number value (global 'x')
  [...]
> #3
0

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Andrew Starks


On Sunday, November 23, 2014, Roberto Ierusalimschy <[hidden email]> wrote:
It is funny (and a little sad) that, with all this disussion about the
length of numbers, nobody noticed that 5.3-beta has a bug there:

Lua 5.3.beta  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> x = 3
> #x
stdin:1: attempt to get length of a number value (global 'x')
  [...]
> #3
0

-- Roberto

...or telling.  
Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tony Papadimitriou
In reply to this post by Roberto Ierusalimschy
It's all very subjective.  I see two bugs :) 1. Wrong error, and 2. Wrong
number

-----Original Message-----
From: Roberto Ierusalimschy
Sent: Sunday, November 23, 2014 9:31 PM
To: Lua mailing list
Subject: Re: ## operator (error)

It is funny (and a little sad) that, with all this disussion about the
length of numbers, nobody noticed that 5.3-beta has a bug there:

Lua 5.3.beta  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> x = 3
> #x
stdin:1: attempt to get length of a number value (global 'x')
  [...]
> #3
0

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Tim Hill
In reply to this post by Tony Papadimitriou

 
In simple terms, the length of a number is how that number would be represented if you were to print it out.  No complicated rules.  No super science.  If I can convert the number to a string and get its length, then that’s the number I’m looking for.
 

So why don’t you just do that? What is the purpose of trying to make numbers and strings interchangeable? A number, as an abstract idea, is totally different from an array of characters. The fact that they have similar representations in source code doesn’t in any way mean they are in some way the “same” concept, and more than a photo of an elephant and a photo of a pizza (as photos) makes them the “same”.

imho, trying to make “123” behave like 123 just confuses beginners; it lulls them into a false sense of security that strings are somehow “the same” as numbers when they are not. It’s not long before a student is writing, “1” + “2” all over the place and finally wonders why “1 + 2” doesn’t give him/her 3. And at that point you have to explain why and then comes the inevitable question: “If they aren’t the same why does “123” work then?”. Overlapping types in this way simply causes confusion for beginners and experienced developers alike imho.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: ## operator (error)

Axel Kittenberger
In reply to this post by Tony Papadimitriou
But these ‘alphabetic numeral’ strings that (obviously) denoted nu
To help you understand my point better, think of a very simple and common application.  If you want to center a number within some fixed length (say a terminal screen of fixed width), you need the length of the number (in whatever representation that number is to be shown) so you can subtract it from the total available length, and add half that number of spaces to the front of the string to center it.  Simple?
 
Id rather have a print function that understands output ought to be "right aligned". As the length depends on output function and how it wants to represent the number. 

We can argue that in computers there isnt a true abstract notion of a number. It always has to be represented in some form. In that case the length in any modern computer is always 64bit.
 
But isn’t the same true for language words?  Any word’s length is based on its representation in a given language, or even in the same language with multiple valid spellings.  In English, for example, some say potatoe, some say potato (regardless of which form you consider correct, that’s irrelevant.)  Same length?

Yes, but there is no automatic coercion when a "potatoe" is put in an elevator versus a lift.

BTW: Unless there was some deeper meaning. Potatoe is an unlucky example, as no where in the world it is considered to be a correct english word. https://www.google.at/webhp?#q=potatoe&nfpr=1
 
In simple terms, the length of a number is how that number would be represented if you were to print it out. 

Which is affected by the system locale.
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] ## operator

Tom N Harris
In reply to this post by Soni "They/Them" L.
On Saturday, November 22, 2014 11:28:01 PM Thiago L. wrote:
> On 22/11/14 10:04 PM, Tom N Harris wrote:
> > So what you're really saying is if you want to track the number of items
> > in a table, the best way is to code your own item-counting class using
> > metamethods.
> Doesn't solve the problem for arbitrary input.

Then the problem is overloading plain tables for uses beyond its intrinsic
contract. You're asking for a specific policy (items must be countable) but
want to accept tables that don't promise that policy. If you need countable
tables, then only accept countable tables. Or convert uncounted tables to
countable tables when encountered, or fast-path countable tables but fall back
to slow iteration of uncountable tables.

That's what the comparison to Java elucidates. Advanced behavior comes about
by creating classes. In Java they're necessary and unavoidable, so you put
needed policy in methods without giving it a second thought. But Lua classes
are optional so it's easy to overlook when a class, or something class-like,
would be prudent. Java doesn't have a built-in associative array; it's
implemented as a class. Lua doesn't have a built-in countable container; it
must be implemented with metamethods.

Saying "but what do I do if the user passes a plain table to my Lua function?"
is like saying "but what do I do if the user passes a plain Array to my Java
function?" except you're told explicitly what happens by the type system.

--
tom <[hidden email]>

12