Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simplifying the logic in the isNumber function in pygmykernel.py #2

Open
franksergeant opened this issue Jul 27, 2019 · 2 comments
Open

Comments

@franksergeant
Copy link
Contributor

I received these comments via email:

I learned isdigit will match some non-decimal number systems,
so just for fun, I tried to paste in a Kharosthi number from
Wikipedia. It didn't work, Windows and Python spoiled the fun
with character encoding complexity before it could even get to
int().

Huh... int() will refuse to convert a string containing a
decimal point. That's technically good, it would remove any
possibility of mismatch between what could be an int and what
our if statements determine. It could be used with try...except
just like floats, but I wouldn't want to indent the rest of the
function inside the except block. What do you think of the
following code which uses return to elide further flow
control? "pass" here signifies "ValueError doesn't matter yet,
there are other things to try." Sorry if I'm fussing too much,
I'm still developing my programming style.

try:
    return (True, int(s))
except ValueError:
    pass
try:
    return (True, float(s))
except ValueError:
    pass
# (then try chars & hex)
@franksergeant franksergeant changed the title simplifying the logic in thi isNumber function in pygmykernel.py simplifying the logic in the isNumber function in pygmykernel.py Jul 27, 2019
@franksergeant
Copy link
Contributor Author

Thank you for the suggestion.

I want to think about it some.

I like the idea of simplifying it. I would still be inclined to test explicitly for a leading dollar sign (signifying a hex literal), a leading hyphen (signifying a negative number of some sort), and a leading apostrophe (signifying a character literal).

Do/should we allow negative hex literals (I think not?).

Do/should we allow word names to start with a dollar sign or apostrophe?

I need to think about it (and cannot right now).

@eekee
Copy link

eekee commented Aug 12, 2019

I'm glad my rambling was interesting.

I'm posting mainly to test, I can't give any of this any deep thought right now, but have a couple of surface thoughts:

Negative hex literals raise the question of whether to display them in signed or unsigned format, etc. I'm generally not in favour of adding features to deal with such questions. :) Lots of languages do without them anyway.

I like Forth's way of searching the dictionary first, before checking if it can be converted as a number. I don't see anything wrong with it, although my experience with Forth is limited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants