LiquidGravity wrote:
If the only reason is to make it easier by preventing confusion then I don't think this will make it easier.
I do. It solves the second of the two "big changes" from the v2 plan:
Chris wrote:
The burden of maintaining backward compatibility with legacy features reduces the usability and convenience of the language. The two big problems are that:
- IF-statements must usually be enclosed in parentheses to be expressions, which is a big source of confusion and script-bugs.
- The equal-sign operator does not assign an expression, so statements like x=y produce a counterintuitive effect. Even after users get used to it, they're still prone to type = instead of :=, which is a big source of script-bugs.
(The equal-sign operator still does not assign an expression, but statements like x=y don't pass through unchecked, so it won't be a source of bugs.) Frankly, I'm not willing to consider keeping = as literal assignment.
Quote:
If you want to get rid of one why not get rid of expression assignments := and instead use traditional with forced expressions?
Firstly, that would be completely pointless. You'd still have two types of assignments, just that they'd be written as = and =% instead of = and :=. In fact, = with forced expression (% ) is internally translated to :=. Secondly, := is valid in the middle of an expression such as
If(retval := func()), whereas "% " is only valid at the beginning of an "arg" in command/traditional mode.
Quote:
; versus this mess:
You're right to call it a mess. Why did you use double-derefs in the second example? Also, why explicit concatenation? Well, I can guess it's because you were
trying to make the code unreadable to further your point. Anyway, these do work in the current alpha:
Code:
Var := "
(
Line 1 of the text. %SomeVar%
Line 2 of the text. %SomeVar2% By default, a linefeed (`n) is present between lines.
)"
Var := "The variable MyVar contains %MyVar%."
... and there was talk about allowing this:
Code:
Var := "
Line 1 of the text. %SomeVar%
Line 2 of the text. %SomeVar2% By default, a linefeed (`n) is present between lines.
"
How it handles the leading/trailing `n or indentation may be the topic of another discussion.
Quote:
Btw wrapping percent signs around the variable name can sometimes prevent the incorrect variable from being used. I hope that it remains as an option at least.
At the moment I'm inclined to keep the double-percent-sign method, but
%(var) would be more consistent; i.e. because each
% would introduce exactly one variable. Instead of
"%var1%%var2%_
%var3" you could write
"%var1%(var2)_
%var3".
jethrow wrote:
This would be particularly nice if it applies to a Class definition
If supported, a
class definition would purely be syntax sugar for defining a base/prototype object. Static class variables, if supported, would merely be fields in the "class" object rather than variables or fields in the derived object.
HotKeyIt wrote:
Will [using command syntax to call a function] be possible at some point?
I have mentioned in passing that I want to make commands and functions equivalent, allowing either syntax in every case. However, there may be difficulties with user-defined functions:
Code:
#MustDeclare
GetFoo foo, some text
#MustDeclare Off
...
GetFoo(ByRef aFoo, aBar) {
aFoo := CalculateFooFromBar(aBar)
}
At the point the command is parsed, GetFoo hasn't been defined, so the parser doesn't know how many or what type of args it has. GetFoo's args can be processed at a later stage, after the function is resolved, but in that case the positional behaviour of var declarations/var references/#MustDeclare would have to be changed.
This problem could be avoided by marking all args of user-defined commands unconditionally as literal text (and probably requiring literal commas to be escaped even in the final arg); but in addition to making the usage less intuitive, it would rule out the possibility of overriding built-in commands (which have output variables) the same way built-in functions can be overridden. On the other hand, for user-defined commands to provide the same amount of flexibility as built-in ones, there'd need to be some way to indicate a parameter should be an expression (as with
WinMove x+n, y+m) or an input var.
There are other problems with the positional behaviour of var declarations/var references/#MustDeclare which I hadn't considered until recently. The main use I had in mind for super-global variables was for "constants" like WM_USER, which could be defined in a library file. However, for the main script to be able to reference it, the library file would need to be explicitly #included prior to the script's first use of the variable. Similarly, if a class definition caused a super-global variable to be introduced (containing a class/base/prototype object), scripts would need to include that class definition at the top of the file to be able to reference any static class variables or instantiate the class.
Functions don't need to be declared in advance because they're resolved at a later stage than variables, after all lines have been parsed but immediately before each expression is fully processed.
Login
Register
FAQ
Search
...
