You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @VinGarcia - sorry, I just realized I overlooked this from a few months ago. I think we've partially added this, like for string concatenation. I'd also be okay adding it for the other expressions. You can keep this issue open if you were planning on adding it and close it otherwise.
It would be even better if we could think a way toggle the flavor of the syntax between the C, Python and others. I mean python-like syntax is just a personal preference. But I can't think of a good way to do that for now =/.
I will convert most things to a python style then.
I was thinking about this Issue, and I think that since this is a framework this kind of decision should be made by whoever uses the library. In future we should plan a way to make calculator extensible so that this kind of choice could be made by the user of the library.
Hello @bamos, with the multi-type support I am presenting on my pull request we will have the option to work with:
etc.
What if we try to mimic python operations and syntax.
Until now we were following C standarts, so
true
is the same as1
andfalse
the same as0
,there were no boolean type, and no string operations.
Do you think it would be a good idea to borrow syntax from Python? I like it and it is usually easy for the user to understand what is happening.
This changes would imply in:
^
to**
true
reserved word would change toTrue
, and the same forfalse
+
And some other stuff.
What do you think? Is this a good a idea? May I proceed?
The text was updated successfully, but these errors were encountered: