keith-packard / snek

Snek programming language for tiny systems
GNU General Public License v3.0
294 stars 30 forks source link

inconsistency questions #75

Closed incanus closed 1 year ago

incanus commented 1 year ago

By no means do I mean this in a critical way; I'm more curious a) if these are expected and b) if you have seen practical confusion or questions around these in your educational uses.

I notice an "identity issue" with both floats and booleans. This is on a Mac, but I've seen it when compiled in a custom ARM embedded environment as well.

> 5.3
5.30000019
> 1.2
1.20000005
> True
1
> False
0
> 3==3
1
> False==False
1

That is, while practically correct (1 and 0 are still truthy and falsy), my expectation would be that a REPL would reflect the values entered, not equivalents. And I'm not sure what to think about the floats or how this might manifest.

And the last bit is more of a nitpick related to full Python parity. I notice that input() can take a variable number of arguments.

snek_poly_t
snek_builtin_input(uint8_t nposition, uint8_t nnamed, snek_poly_t *args)
{
        [...]
    while (nposition--) {
        snek_poly_t arg = *args++;
        snek_poly_print(stdout, arg, 's');
        [...]

But normal Python only accepts one argument.

keith-packard commented 1 year ago

> 5.3
5.30000019
> 1.2
1.20000005

Yeah, welcome to floating point? The question was whether snek should print enough digits to exactly represent all floating point values or few enough to trim off these extra digits. I decided to show all of the digits so that you could re-enter values that were printed precisely. Given that there isn't any way to adjust the format used, I had to pick a constant and chose 9 digits.

True 1 False 0 3==3 1 False==False 1

For these, it's an efficiency question -- providing explicit True/False values requires a bunch of mechanism in the implementation (which takes a bunch of memory). I decided that wasn't worth it.

And the last bit is more of a nitpick related to full Python parity. I notice that input() can take a variable number of arguments.

But normal Python only accepts one argument.

Oh, I wonder why I did that. I could save some memory by changing that...

keith-packard commented 1 year ago

oh, now I know -- the prompt parameter to python's input function is optional, with a default value of ''. It was much shorter to just support a variable number of arguments than support an optional parameter. But, it would be even shorter if it only allowed zero or one parameters.