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

Function syntax suggested improvements #3

Open
Fleker opened this issue Apr 13, 2021 · 2 comments
Open

Function syntax suggested improvements #3

Fleker opened this issue Apr 13, 2021 · 2 comments

Comments

@Fleker
Copy link

Fleker commented Apr 13, 2021

Generally I like the format of aligning the syntax with Python. Here's a few suggestions to make it more idiomatic.

Function Declaration

Should we define out as the return var or make it predetermined based on parsing the return statement? Python typing doesn't specify the variable name, just the type.

Also, you shouldn't need to specify multiple return type values. For

def funcname(
    in1: int16,
    in2: float32
) -> (
    out1: float32, 
    out2: int8
):
    #Body of the function

This would not happen as you'll only be able to return an array if they're the same type, as that's a limitation in languages like C. So you could simplify to something like

def funcname(
    in1: int16,
    in2: float32
) -> list[int8]:
    #Body of the function

Otherwise the rest looks good.

@polfeliu
Copy link
Owner

polfeliu commented Apr 13, 2021

I also like to be aligned with python however I specified this because cyanobyte spec only allows to return a variable once in the logic, at the end of the function. If statements are not in the spec for now, and it could be tempting to return different variables based on some logic if they were implemented.

TBH I though they were and thats why I stuck with that.

Maybe a better answer is to force the return statement at the end of the function declaration and leave the def() as pure python.

The spec definition says "variable or variable array", the particularities of the compiled language are another thing. If I implement return statements it doesnt matter then.

return var1
return [var1, var2, var3]

To clarify: This last one can be in a preripheral yaml as a yaml list. If the types od the variables are different the C template should throw an error.

@Fleker
Copy link
Author

Fleker commented Apr 15, 2021

Yeah I can see that there may be some potential for logical errors. Depending on how you want the parser to work, you could add validation in each function. Common text editors are able to perform type inference and will know if the return type doesn't match the function signature. But that may be extra work that is unnecessary.

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