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

[Bug] Type conditions should be lazy evaluated #125

Open
jon4hz opened this issue May 28, 2024 · 8 comments
Open

[Bug] Type conditions should be lazy evaluated #125

jon4hz opened this issue May 28, 2024 · 8 comments
Labels
bug Something isn't working compiler enhancement New feature or request

Comments

@jon4hz
Copy link

jon4hz commented May 28, 2024

Currently type condition's aren't lazy evaluated which causes the following code to fail:

fun choose(options, ref result): Bool {
    let res = $gum choose {options}$ failed {
        return false
    }
    if result is Text {
        result = res
    } else {
        result = parse(res) failed {
            return false
        }
    }
    return true
}

let fruits = ["apple", "banana", "cherry", "orange"]
let fav_fruit = "none"
echo "What's your favorite fruit?"
let success = choose(fruits, fav_fruit)
if {
    success: echo "Your favorite fruit is: {fav_fruit}"
    else: echo "More of a meat type?"
}

Error: Cannot assign value of type 'Num' to a variable of type 'Text'

@b1ek
Copy link
Member

b1ek commented May 29, 2024

i am confused. why should this code work? result is clearly Text here.

you want an Any type, right? or something like OneOf<[Text, Int]>

@jon4hz
Copy link
Author

jon4hz commented May 29, 2024

i am confused. why should this code work? result is clearly Text here.

Yeah in this example result is Text but result could be also a Num, so this example shouldn't cause a compiler/transpiler error. I mean, that's the entire point of the type condition...

@Ph0enixKM
Copy link
Member

Ph0enixKM commented May 29, 2024

It should work like so @b1ek:

fun foo(val: Text) {
  if val is Text: val = "hello"
  else: val = 12
}

foo("test")

The function should not throw error. Because the value will always be Text so the else clause will never run.

Right now it errors that val = 12 is incorrect as it's unable to assign Num to Text

@Ph0enixKM
Copy link
Member

I think this issue should only cover type evaluations that can be known at compile time. We fallback to the regular behavior when some arithmetic comparison is detected.

@b1ek
Copy link
Member

b1ek commented May 29, 2024

Do types even exist at runtime?

I mean, this code:

let var = "hi!";
if var is Text {
	echo var
}

compiles to this:

__0_var="hi!"
if [ 1 != 0 ]; then # the "if var is Text" part
    echo "${__0_var}"
fi

and 1 is obviously not 0

@Ph0enixKM
Copy link
Member

@b1ek Types do not exist at runtime. All var is Type resolve at the compile time

@Ph0enixKM Ph0enixKM changed the title Type conditions should be lazy evaluated ✨ Type conditions should be lazy evaluated Jun 4, 2024
@Ph0enixKM Ph0enixKM added this to the Amber 0.4.0-alpha milestone Jun 17, 2024
@Mte90 Mte90 added the enhancement New feature or request label Jun 24, 2024
@Ph0enixKM Ph0enixKM changed the title ✨ Type conditions should be lazy evaluated [Bug] Type conditions should be lazy evaluated Jul 7, 2024
@Mte90 Mte90 added the bug Something isn't working label Jul 9, 2024
@Mte90 Mte90 added the compiler label Jul 19, 2024
@mks-h
Copy link
Member

mks-h commented Sep 17, 2024

The function should not throw error. Because the value will always be Text so the else clause will never run.

@Ph0enixKM, that's called dead code, and it should be errored out at compile time. But the originally discussed issue simply asks for union types.

@Ph0enixKM
Copy link
Member

@mks-h That's something else. It's simply what Typescript is doing with the if's that can narrow down the type of variable when conditioned:

const test: string | number
if (typeof test === "number") {
	// Here `test` is of type `number` and not `string | number`
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants