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

🖊️ Preserve localization information for numbers and booleans #5676

Merged
merged 11 commits into from
Aug 12, 2024

Conversation

boryanagoncharenko
Copy link
Collaborator

@boryanagoncharenko boryanagoncharenko commented Jul 26, 2024

Fixes #5548

Goal

The goal of this PR is make Hedy understand and preserve localization information when using numbers and boolean values. In other words, if the user types 1 + 1 the output should be 2 and if the input is ١ + ١ the output should be ٢. Similarly, if the user types a = True\nprint a the output should be True and if the input is a = Вярно, the output should be Вярно. The numeral system or the textual representation of the boolean values should not be based on a static setting somewhere in the user profile. The localization information of the input and output should be dynamic.

Brief implementation notes

To make Hedy understand what numeral system or boolean values the user is using, I had to change the basic types of the transpiled code. So before, when the user executes a = ١, we would transpile it to a = 1. Now, the variable needs to be assigned to a type that not only holds the real value of 1 but also the localisation information, e.g. that the Arabic numeral system is used. The value is now transpiled to a = Value(1, num_sys=‘Arabic’). Similarly, for booleans we store information about the textual representation of the value: b = waar becomes b = Value(True, bools={True: ‘waar’, False: ‘vals’}).

Later, when the variable is referenced, we decide whether to use the real value or the presentation value based on the command. For example, if the variable is used in + operator, we definitely need the real value (1 and True). However, if the variable is used in a print or ask command, we need its presentation (١ and waar).

Let me give you a few more examples, so that you get a better understanding of the changes:

pi is 3.14
print pi

# now becomes
 
pi = Value(3.14, num_sys='Latin')
print(f'''{pi}''')
x is 1 + 2
y is x + 3

# now becomes

x = Value(1 + 2, num_sys='Latin')
y = Value(sum_with_error(x, 3, """Runtime Values Error"""), num_sys=get_num_sys(x))
field = '.', '.', '.'
field at 1 = 'x'

# now becomes

field = Value([Value('.'), Value('.'), Value('.')])
field.data[int(1)-1] = Value('x')

Issues addressed as a side-effect
In order to make this change possible, a few issues had to be addressed on the fly:

  • In levels 6 - 11 the following code works successfully in Python (prints 'jahoor') but fails to print in Skulpt. The reason is that Skulpt does not recognize the non-Latin numbers as numeric (i.e. '٢'.isnumeric() returns False). The issue now resolved.
nummer1 is ٢
nummer2 is 2
if nummer1 is nummer2 print 'jahoor!'
  • In level 12 we say quotes need to be used everywhere, including in list definitions but we could add a non-quoted value to a list. Since this introduces complexity in the transpiler and no example ever uses this 'exploit', I have rewritten the grammar of list addition to match the one for list creation.
  • In level 14 an equality check with undefined variable succeeds. The issue is now addressed and quotes are required for non-variable strings:
naam = 'Hedy'
if naam == Hedy # This should raise an undefined var error
  print 'hedy'
all is 50
turn all
  • In level 2 print does not escape variable names when they are reserved words. Thus, the following program yields sum instead of 2. However, if we change the name of the variable to sun, it outputs 2.
sum is 2
print sum
  • In levels 6 and up, the play command cannot take non-Latin numbers. The issue is now resolved.
play ٣١
play ٣١ + ٣١
n = ٣١ 
play n

How to test

Few of the unit tests can verify that the desired output is produced and, also, there are substantial differences between Python and Skulpt. Thus, the only way to ensure that the change does not lead to regression is to execute the main scenarios of all commands in the browser and manually validate their outcome.

Please check that no other functionality is broken, e.g. variable list appears correctly, debugging works as expected, etc.

@jpelay jpelay added the language Issues related to the Hedy language label Jul 31, 2024
Copy link
Member

@jpelay jpelay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love the change, and that you addressed so many issues with it.

I tried every example and all of them worked! I think this is ready to ship it :D

Copy link
Contributor

mergify bot commented Aug 12, 2024

Thank you for contributing! Your pull request is now going on the merge train (choo choo! Do not click update from main anymore, and be sure to allow changes to be pushed to your fork).

Copy link
Contributor

mergify bot commented Aug 12, 2024

Thank you for contributing! Your pull request is now going on the merge train (choo choo! Do not click update from main anymore, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit 164d59d into main Aug 12, 2024
12 checks passed
@mergify mergify bot deleted the localize_output_5548 branch August 12, 2024 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language Issues related to the Hedy language
Projects
None yet
Development

Successfully merging this pull request may close these issues.

🖊️ Preserve language of booleans and numbers in output
2 participants