As far back as I can remember, any routine that used Boolean could be evaluated not only as TRUE and FALSE but also zero (0) and (1) or minus one (-1).

Strangely you cannot do this in Pico-8. I'm wondering if there is a reason for this as it would be a simple matter to make global definitions of TRUE to equal 1 and FALSE to equal 0. A conditional statement without an argument would simply be any non-zero number.

if (apple) takeabite()

So this would evaluate true provided the variable apple, boolean or otherwise, evaluated to any number besides zero.

For that matter I am understanding that SGN(0) also reveals 1 whereas all other programming languages I've known show it to be zero. What is the reason for these identities and lack thereof ?

Now NIL is a special case and I kind of understand why it exists. It says that this item has not been defined. Not that it equals zero or empty string of "" ... no, simply NIL. Yet when attempting to evaluate NIL as being less than 1 or equal to zero or less than an empty string of "" or equal to that selfsame empty string "", you get a type mismatch error.

And maybe for NIL, this is a good idea. What are your thoughts on these logical and functional operators ?

"What is the reason for these identities and lack thereof ?"

The reason is just that it's the way Lua does it. In fact, I'd guess most modern languages do that. Casting booleans to numbers (like C++), or even implementing them as integer enums behind the scenes (like C and languages inspired by it) can create all kinds of messy situations when you want to be able to return values of multiple types, which is common in dynamic languages. JavaScript is an example of a language where this aggressive casting makes for some weird stuff: wat

Of course, many languages, including Lua, has a concept of "truthyness" and "falsyness". In Lua, for example, all values evaluate to "true" when used in boolean expressions, except "false" and "nil". You'll see variations of this in pretty much all modern languages. Is this what you're actually talking about? You wish that 0 was evaluated to "false" in Lua, like in Python, where the empty string, the empty list, and 0 are all "falsy"?

Pretty well. That's what I grew up on. Actually if just the IF (**) statement without a condition would evaluate as TRUE for any non-zero number or string greater than "" would be fine with me.

What about SGN() ? That has always evaluated to zero for a zero number in any language I've worked in, including fairly modern BlitzMax and B4GL.

I guess while we're on the same line. Is it really necessary to use parenthesis for calls of functions ?

Once again basics like BlitzMax and B4GL do not require it.

plotrec a,b

Where "plotrec" is a function. Now if there were a value returned, naturally there would be parentheses.

c=plotrec(a,b)

Also why two equals signs for a comparison ? No basics I have ever worked in ever had that. If you wanted to do a comparison, you had < <= = >= <>. Also not equal is != and not <>.

I know there must be a method to this madness, but this old-school programmer is puzzled for what clearly is confusion. The double equals. The inability to check for a non-zero number or string greater than an empty set, and SGN(0) to strangely equal 1.

Don't get me started on the graphics though. All kinds of things I had to learn, the least of which is X2 and Y2 for coordinates to rectangles is the END location, not the actual size across and down added to X1 and Y1 which is standard.

These are just some of the many differences between languages.

I agree that it's weird that SGN(0) does not return 0. It actually does in standard Lua, as far as I remember. I wonder if this might be a bug.

Stuff like requiring parentheses just comes down to how the language is parsed. Lua is a single-pass compiled (to bytecode, that is) language. As an example, this is the reason += and -= is not found in regular Lua; the compiler would have to do two passes on a statement like that to assign the correct value. (zep was nice enough to add those to PICO-8's Lua, however, which I assume is not single-pass.) Someone correct me if I'm wrong here.

Ruby does not require parentheses around function arguments either, but Python does. So does the C family of languages (with which I assume you're familiar, and which is also an old-school language). Lua does too, although you can (as you know) drop them if the only argument is a string or a table.

Two equals signs for comparison is so common in today's programming languages (post-C) that it's actually pretty baffling that you've never encountered it (and I mean no offense). You can read more about the history on Wikipedia: https://en.wikipedia.org/wiki/Assignment_(computer_science)#Assignment_versus_equality

The "not equals" operator in standard Lua is actually not !=, but ~= (which also works in PICO-8). I'm happy zep added != for PICO-8.

"No basics I have ever worked in ever had that."

But Lua isn't a BASIC language! I don't understand why you even mention that, and call the differences between Lua and BASIC "confusion". They have very few things in common.

I have to ask: Is BASIC the only family of programming languages you knew before Lua? There's a lot of diversity out there.

And you didn't even mention the one "gotcha" that every new Lua programmer is aggravated by: That tables start at index 1, not 0 like arrays do in pretty much all other languages ;)

By the way, Lua is 25 years old, so it's not really a baby language any more either. (Although of course it took time for the language to grow popular.)

Basic is pretty well listed in my chart. I did program years ago in some easy 6502-assembly, Turbo Pascal, Lattice C, and a bit of Javascript (deciding I didn't like it at all after a month).

Basic is, has, and always will be strongest in my head for programming.

And yes, that gotcha also exists in B4GL. I finally got used to it so its not too bad. Zero really would be nice though as I think that's standard.

I'm hoping this language eventually adopts the ability to LOAD and SAVE true text files. I guess we're not there yet ...

Sat down to watch WAT. WOW ! Those are 2 very messed up languages. If I was the author of those languages I would DEFINITELY have fixed some of those incredibly gross errors so you wouldn't get them.

{}
unknown
{}+[]
unknown
[]+{}
unknown
{}+{}
unknown

a[4]=3
array created, value set

tobiasvl: You are correct that extensions like += are implemented in a second pass. In fact to implement these Pico-8 is just making a syntactic transform prior to passing it to the stock Lua 5.2 interpreter. That's why some of the language extensions are sensitive to line endings and such.