search

goby-lang / goby

Goby - Yet another programming language written in Go
MIT License
3.49k stars 171 forks source link

Document (or fix, if it's a bug) the boolean string literals #450

Closed 64kramsystem closed 6 years ago

64kramsystem commented 6 years ago

I've noticed that in Goby, the string literals "true" and "false" directly translate to boolean values (respectively, true and false).

Since this behavior is unique among the scripting languages (Ruby/Python/Perl/PHP), I was wondering if this is intentional or not.

If intentional, I think this should be very carefully evaluated, in particular because of undefined/unexpected behaviors:

if false; echo "not printed"; end #=> evaluates to false
if "false"; echo "not printed"; end #=> evaluates to false
if "False"; echo "printed!"; end #=> evaluates to true
if "fa" + "lse"; echo "printed!"; end #=> evaluates to true (!)
("false").class #=> Boolean
("fa" + "lse").class #> String (!)

In essence, the strings "false"/"true" evaluate to Boolean, but not consistently - they do if they're literals, they don't if they're string variables.

If it's a bug, I can easily fix it (it's in VM#initObjectFromGoType).

st0012 commented 6 years ago

@saveriomiroddi Thanks for reporting this, it's a bug. But I'm not sure if it can be solved easily. Because in instructions we only have string format, this is why we can't distinguish whether it's bool or string (they are both string in the instructions). So I think the proper way to fix this is to add a new instruction called PutBool.

64kramsystem commented 6 years ago

@st0012 What do you think of having Putobject use Object rathen than string literals? This would make the instruction set a little simpler, rather than having specialized instructions like PutObject <string>, <PutBool <boolean>, etc?

Are there any specific advantages in having more, specialized, PutObject intructions?

If you think a generic PutObject version would be OK, I can start working on it (this would also solve this (#450) issue.

st0012 commented 6 years ago

@saveriomiroddi Having separate instructions can make things simpler actually, this issue is caused by dealing too many things in one function. If having more instructions can simplify the evaluation logic of different kind of action, then it's worth it.