-
Notifications
You must be signed in to change notification settings - Fork 15
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
Variable declaration and scope #150
Comments
Currently I'm leaning to limit the scope of local variables to the block they're declared in. I want this code to generate compile-time errors, for example:
but this one to compile:
That wouldn't be possible with making the variable scope equal to the whole function. The two instances of the same variable should probably get compiled to different mlog variables, so that the second instance doesn't "inherit" the last value of the previous instance. I'm not entirely decided about this yet. |
Version 3.0.0 will probably support optional variable declaration as an experimental feature. Three kinds of variables will be available:
Using undeclared variables will be supported alongside optional declarations with normal rules:
A declared main/local variable will hide a global variable, a parameter or a constant with the same name. For now - and maybe never - there won't be a mechanism to access a global variable hidden by a local one. A compiler option will probably be added to generate warning or error when an undeclared variable is encountered. Declaring a variable which was already used without declaration, as well as declaring a variable twice, will result in an error. For the future, the following changes are planned:
|
Implementing variable declarations, as described above, might lead to a global variable mapping to the same mlog name as a main variable. To this end, I'll change the way variable names are transformed to mlog:
Once modules become available, a module prefix of the form This is what a nontrivial compiled code would look like:
|
Implemented in 3.0.0. The visibility issues will be solved as part of module implementation. |
See also #148 and #149.
New variable declaration syntax needs to support the following variable types and initialization:
public
is visible among all modules.private
is only visible inside the declaring module.public
/private
) is accessible from other modules, but only by using full module name or throughimport
.__m01_X
is a private global variableX
in the first module.Mindcode compiler will emit a mapping of variable names to mlog identifiers for reference.
We need a homogenous, intuitive syntax covering the requirements given above. A C-style syntax comes to mind.
public
orprivate
.volatile
,aliased
,restricted
andlinked
may be used on internal variables.var
is optional in that case.declare
?)var
will be required. If types are introduced one day, a type name would be used in place ofvar
.var
not needed (or outright forbidden, probably forbidden) forExamples of declarations:
Generic syntax
Internal variables:
External variables:
Linked variables:
Linked variables are automatically public in global namespace. No initialization.
Not all of this will be supported from the get go, but it is important to get the syntax right.
The text was updated successfully, but these errors were encountered: