doWhile function creates an infinite loop if the program contains words that contain "do"

[Nico314159]

For example, the program that consists only of

import random

traps the parser in an infinite loop because random contains the word do.

[Nico314159]

@xXCrash2BomberXx not sure exactly what part of the doWhile function does it, but this is definitely the cause as import rand lacks this issue entirely

[xXCrash2BomberXx]

I put up a new version of string.py that should hopefully fix that, lmk if that works for you!

edit: and a new build of bython.exe to accompany it if that's what you use

[Nico314159]

Seems to work now.

[Nico314159]

@xXCrash2BomberXx Found another strange issue.

if isinstance(expression, tuple) {
    output = valuation[expression[0]]
    string[expression[1]] = bool_to_int(output)
    return output, string
}

This code doesn't parse correctly, unless I add parentheses around output, string

[Nico314159]

Also term_index++ becomes term_((index:=index+1)-1) when it should be ((term_index:=term_index+1)-1), and i //= 2 just turns into i (probably because parser can't distinguish between comment and floor division)

[xXCrash2BomberXx]

@Nico314159 The return tuple you mentioned I actually hate and don't get why Python added it in the first place. I'll have to look if it's a fix I can even make to the parser without it breaking everything bc otherwise you may just need to use explicit parenthases.

I'm not encountering the issue you described with term_index++. I did find an issue with _ in for loop variables that I'm fixing, but I can't replicate the issue you described with that. Do you have a code block that would showcase this bug?

The floor division is removed due to comments in this, but I may consider adding a compiler flag to allow floor division and remove the single line comments.

edit: I can't get the first block you gave to error out either so could you provide either more context or an example written to show the specific error?

edit 2: I hate your lack of semicolons in the code block you gave. You're lucky I still parse regular indentation to some degree

[Nico314159]

Error for first block: the output file keeps the curlies instead of changing it to python's syntax.

if isinstance(expression, tuple){
    output = valuation[expression[0]]
    string[expression[1]] = bool_to_int(output)
    return output, string
}

Parenthesizing the tuple gives

if isinstance(expression, tuple):
    output = valuation[expression[0]]
    string[expression[1]] = bool_to_int(output)
    return (output, string)

as expected

Way to replicate term_index++ error:

for char in expression {
    # Skip spaces
    if char == " " and bracket_count == 0 {
        index++;
        if pad_bool {
            term_index++;
        }
        continue;
    }
    pad_bool = False;
}

(It doesn't throw an error to console while parsing, but look at the compiled output code and it will contain term_((index:=index+1)-1))

PS: Issue persists regardless of semicolons, but yes I'll make sure to include them going forward

[xXCrash2BomberXx]

Oh, I see what you mean. For the first one, that's actually a limitation with the way the parser works. For it to differentiate between a dictionary/set and a context declaration, it checks if a comma is in the immediate scope. If a comma is, it assumes it's a dictionary or set, otherwise, it assumes it's a context. Because of this, you not wrapping the return in parentheses makes the compiler assume it's a dictionary/set making them required. That's not something I can fix and as I already mentioned, I hate that the syntax is allowed in python since imo, it never should have been added

[Nico314159]

Gotcha. How about the ++ issue? Speaking of, is it also possible to make myVar ++; (with the space) valid? (right now it complains about ++ not being directly connected to the operator)

[xXCrash2BomberXx]

I'm looking at that right now and it's strange that the ++ has an issue but the -- works fine. I'll have to see what's different but it shouldn't be that hard of a fix. I'll have to look at how hard the space would be to include.

[xXCrash2BomberXx]

I found the issue, I'll push a fix in a sec.

Edit: The issue was that the replace function was replacing all instances. Since the first ++ you called was named index, it also found the index part of term_index and replaced that. The new push should fix this issue. I'll take a look at seeing if allowing a space is possible tomorrow when I get a chance but I'll leave this issue open until that is either determined as not being a change or is added.

[xXCrash2BomberXx]

@Nico314159 The newest build should work with spaces around the ++ and -- operators. Let me know if that works for you and if you encounter any bugs with it!