Re: [amibroker] Re: Biggest shortcoming of AFL scripting language, AmiBroker Email List Archive

2009/11/6 scourt2000 <stevehite@xxxxxxxxxxx>

Tomasz,

First off, if we're talking about programming languages in-the-large, I have no earthly idea why you ever decided that global variables in a script should not be remembered between runs of that script. It was your decision as a language designer to diverge from standard implementation practices and *that* is the root cause of confusion if we're going to compare mature, widespread programming languages with AFL.

That being said, I will give you a perfect example of what I'm talking about in reality with another well-known charting package as it compares to AFL and there is absolutely no confusion involved.

We all know that eSignal uses _javascript_ for its chart scripting language. In eSignal's usage of _javascript_ (aka EFS), global variables are, well, global variables. They retain their values through multiple runs of a script in a chart. They are global to the script and also private to that particular script. So, global variables are not shared among different scripts in the same chart or different charts.

But, how did eSignal allow variables to be shared between different _javascript_ (EFS) scripts? Simple...in THE SAME WAY Amibroker does it.

They created 2 functions: setGlobalValue(name, variable) and getGlobalValue(name) or, in example form:

In chart #1, running script A:

var a = 10; // some global variable in script A
setGlobalValue("a", a); // set private global 'a' to a shared global 'a'. note: the global shared "a" could be any name I wanted it to be

In chart #2, running script B:

var b = 0; // some global variable in script B

b = getGlobalValue("a"); // retrieve shared global 'a' and place in private global 'b'

Gee, where's the confusion? There is none. Because you use a function to get and set global shared variables while normal global variables are "global private" (and remembered between runs) in their respective scripts.

Was deciding NOT to have global variables in AFL, in the first place, NOT be remembered between runs of an AFL script a languauge design flaw? The answer is YES! The eSignal example proves that because temporary global variables whose values are overwritten between runs of a script do not have harmful side effects to global variables which don't get overwritten between runs of that same script. The example also showed how eSignal has implemented Amibroker's usage of setting global shared variables between scripts.

By the way, I told everyone in my first post what the answer would be for my request..."nothing is broken, use StaticVarSet/Get".

Note:

ALL programming languages are flawed. But global variables retaining their values for the life of their runtime has never been one of them. Tomasz decided that the phrase "life of their runtime" meant one pass of a script's execution. He had no choice but to create a set of functions in AFL to retain global values though multiple script runs. But you should NEVER use functions to fix language design problems. The only purpose of the StaticVarSet/Get family of functions should be to share variables between DIFFERENT scripts, not to provide persistence within the same script.

I don't know what the ramifications are of changing the semantics of AFL's global variables to be persistent between separate invocations without having to do anything else. Tomasz would be the one to give specific examples of where that would break existing, working code.

What I do know though, is that if there is a problem with changing the semantics, it could easily be fixed to not break old code by introducing a new #pragma statement like:

#pragma persistentglobals

This would make everything transparent from the user's perspective. The old semantics would be retained and the new semantics of using global variables in a script to mean "global private" would have to be requested by "the unconfused" among us. ;-)

There's nothing in this for Tomasz. He doesn't make more money and he could care less if I have to litter AFL code with umpteen thousand StaticVarSet/Get functions to solve the problem on "my side" instead of "his".

But if I were the developer of AFL, it would really bother me and I would fix it so that AFL were easier to read and code.

...but I'm not...so there you go.

--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> I would not call it "shortcoming" at all. It would be shortcoming if there was NO static variables,
> but they *are* available.
> Sure you can complain that you need to type few more letters to read/store static variable,
> but the functionality is there and what you call "shortcoming" is rather (in)convenience.
>
> As to the suggestion - actually I was thinking about it BUT... there is one rather important issue:
>
> in contrast to C/C++ where static variables are INVISIBLE to other object code blocks (non-shared, private variables),
> in AFL static variables are in fact GLOBAL SHARED variables. The only common thing is than in both C/C++ and AFL
> the static variables "keep" their values as long as program runs.
>
> Implementing what you are suggesting will lead to confusion and misunderstandings because
> same syntax would have different semantics for C/C++ coders coming to AFL.
>
> If static keyword was introduced it would need to be private, non-shared.
> For strict equivalence to StaticVarSet/Get one would need to introduce completely different keyword,
> such as "shared" or "shared static". Otherwise there would be endless problems with misunderstandings
> of visibility and scope of variables.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "scourt2000" <stevehite@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Thursday, November 05, 2009 9:14 PM
> Subject: [amibroker] Biggest shortcoming of AFL scripting language
>
>
> >
> > AFL needs something like:
> >
> > static {
> > a = 1;
> > b = 2.3;
> > c = "hello world"
> > }
> >
> > The first time the script is read into a chart, the variables within the static{} clause would be created and initialized.
> > Their values would be GLOBAL and REMEMBERED from run-to-run of the script.
> >
> > I know what you're thinking....
> >
> > "Well, you can use StaticVarGet(), StaticVarSet(), StaticVarGetText() and StaticVarSetText() and do the same thing you're trying
> > to show here so what's your point?".
> >
> > My reaction to that kind of question is...HUH?!
> >
> > Oh, you mean you would rather say:
> >
> > "StaticVarSet("a", 3)" or "a = StaticVarGet("a")"
> >
> > rather than:
> >
> > "a = 3" or "a"
> >
> > to have values set/get and remembered between runs of the script (global, yet private to that particular script)?
> >
> > Now, tell me honestly, which one makes YOUR programming life easier and your scripts easier to be read by others?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > **** IMPORTANT PLEASE READ ****
> > This group is for the discussion between users only.
> > This is *NOT* technical support channel.
> >
> > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > SUPPORT {at} amibroker.com
> >
> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > http://www.amibroker.com/feedback/
> > (submissions sent via other channels won't be considered)
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroker.com/devlog/
> >
> > Yahoo! Groups Links
> >
> >
> >
>