Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Should empty variables be treated as 0 in math expressions?


  • Please log in to reply
43 replies to this topic

Poll: Should math expressions treat empty variables as zero? (15 member(s) have cast votes)

Should math expressions treat empty variables as zero?

  1. No, an empty variable should produce an error. (5 votes [33.33%])

    Percentage of vote: 33.33%

  2. Yes, an empty variable should equal zero, but #Warn should provide notification of it. (5 votes [33.33%])

    Percentage of vote: 33.33%

  3. Yes, an empty variable should equal zero, and #Warn should not provide notification of it. (5 votes [33.33%])

    Percentage of vote: 33.33%

Vote Guests cannot vote
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Why should we vote then if your vote is the "strongest" ? I don't have problem with you commanding, but please state that loud, so we don't live in imaginary world.

It's up to you whether to create or participate in polls. Although I've never promised to strictly obey the results of every poll, I value their results and give them a heavy weighting in decisions.

Although it's currently up to me to decide what goes into the autohotkey.com version of AutoHotkey (at least until others join the staff), anyone is free to create and distribute a version of AutoHotkey that has the features they want. Alternatively, one could make a preprocessor script that translates syntax they like into AHK-compatible syntax (this has been done at least once).

I don't see this as an valid reason. There are already number of colaboration breaking directives and NoEnv is not the only one.
...
Coordmode, SetKeyDelay, SetFormat etc.. will all change scripts behavior if not specified so regarding to this new directive will not spoil collaboration as it is already not possible for sure.

I think it is a question of degree: commands like SetKeyDelay -1 are global settings that can be detected and changed by the script while it's running. But directives are "worse" because they alter the behavior of the entire script and its include files.

People get used to NoEnv witch introduced the very same type of problem.

As I said, I expect that #NoEnv will be made obsolete in v2.

This thing is optional and as such can not spoil the languages as it adds new functionality as needed. People that don't want to use it can skip it or even not know for its existance.

Although a directive such as #TreatEmptyAsZero wouldn't "spoil" the language, its presence in the documentation would make AutoHotkey seem more complex, especially to new users. But that is a small drawback compared to the fact that it comes close to splitting AutoHotkey into two separate languages.

THE POINT: New directive can not spoil something that is already spoiled.

Other than #NoEnv, I don't think any of the other language-altering directives are commonly used (such as #EscapeChar). I want to avoid adding any more of them except those that directly help debugging like #MustDeclareVars and #ShowWarnings.

Thanks.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

But that is a small drawback compared to the fact that it comes close to splitting AutoHotkey into two separate languages.

Isn't this overreaction :?:

Ok, you do what you like.... its not something affecting me much anyway... I thought in the some moment that language sophistication is important, as you PMed me as soon as I announced here that I have suggestions in that manner...

I see now that it isn't, so I will stop suggesting things.

Thx
Posted Image

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

I will stop suggesting things.

Isn't this overreaction :?:
;-)
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
No, it is reaction.

I spend lot of time doing this with only one concern - to help the language evolution. Almost all things I did so far were not for my personal satisfaction. Eatch time I create something I look how it can be used by community as a general tool or extension. I basicly suggest things that I learned to be problematic for people who are doing the same thing here. So far only one thing passed, the most unimportant one about colored comments on the site. I don't see why would I keep suggesting things as they are always trown away, even those trivial (like this one)

That shows me who is in command here, breaks some illusions, and generaly proves that Chris and I don't have the same vision of what automatition programming language should be or look like.

As Chris is currently the only developer it has all rights to continue by his wishes. This fact wouldn't change much with new developers. Imagine now I want to update AHK to add this new command. It would have to be code branch as Chris doesn't go along with it...

After all, I find AHK limited more and more eatch day, without alternative solutions to encountered problems as Chris denies to implement better support for low level api access. COM is somehow priority and its domain will likely be limited to MS Office automatiton contrary to native api support witch is limited only by operating system. I guess Chris want us all to make 45ers.

I have a different vision for automatition language.
Posted Image

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Chris and I don't have the same vision of what automatition programming language should be or look like.

That seems true. My original goal for AutoHotkey was that it should excel in hotkeys and automation (primarily the keystroke and mouse-click kind). I want those missions to remain the most important.

Chris denies to implement better support for low level api access. COM is somehow priority and its domain will likely be limited to MS Office automatiton contrary to native api support witch is limited only by operating system. I guess Chris want us all to make 45ers.

I never refused to implement low-level API access (presumably callbacks and easier structs). In fact, I want to -- it's just that I don't know for sure what the priority order will be after #v2.

As for COM, perhaps MS Active Scripting or some other integrated support for other scripting languages would avoid the need to support COM directly. I just don't know enough about it yet.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

primarily the keystroke and mouse-click kind

So remove "atomate almost anything" then from the documentation, and replace it with "automate primarily mouse and keyboard"
Posted Image

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

So far only one thing passed, the most unimportant one about colored comments on the site.

Note it has been done by somebody else than Chris...

As Chris is currently the only developer it has all rights to continue by his wishes. This fact wouldn't change much with new developers. Imagine now I want to update AHK to add this new command. It would have to be code branch as Chris doesn't go along with it...

Designing a language is delicate, and each change will affect a lot of users. Sometime I don't agree with Chris, but I respect his choices.
Even if there were lot of developers, it still need one person, or a committee, to manage the future of the language.
If every contribution was automatically added, we would have a monster language, with both . + and nothing as concatenation operators, much more of C syntax in the language, functions with inconsistent names and parameter order like in PHP, and so on.
I see that in the Lua mailing list: authors read every suggestion, sometime implement some of them, but it is always debated, argued, tested, making sure it fits in the philosophy of the language.
Some changes make some users unhappy (they don't mind breaking things, if it improves the language), some suggestions like making the language more C-like are just ignored.
This can be frustrating, but currently Lua is a nice, small and consistent language.
Note that lot of people hack the Lua code to implement their wishes, they can publish the patch or just use it privately. The only requirement (perhaps obsolete now) is that these versions shouldn't be called Lua, to avoid confusion...

I don't say that AutoHotkey is perfect. But I won't say that Chris as dictatorship over AHK. If that was the case, he would just have answered "No, this is wrong", and wouldn't have taken the trouble to set up a pool and reply here.

After all, I find AHK limited more and more eatch day, without alternative solutions to encountered problems as Chris denies to implement better support for low level api access. COM is somehow priority and its domain will likely be limited to MS Office automatiton contrary to native api support witch is limited only by operating system. I guess Chris want us all to make 45ers.

Not sure what you mean by 45ers.
Com isn't such a priority, as Chris has no knowledge on the topic, so this won't be implemented anytime soon. Note it isn't limited to MS Office automation. There is IE, shell, and perhaps even access to controls in OCXes.
I agree that access to API is important, at least for me.
But I believe you might want to push the language too hard. As you write, it is an automation language, not a full multi-purpose language. Creating fancy menues with big images is nice, but hardly a must have.
Controlling other applications is the main job of AHK, and Com is important for this.
Now, I would like more power in the scripts, that's why I make suggestions toward this, with improved structure handling, support of callbacks, regular expressions, true and associative arrays, and so on.
Chris don't "denies to implement better support for low level api access", he just postpones such features.
He is alone, cannot do everything, want to keep AutoHotkey small and not being a mammoth, including the documentation.
When I learnt PHP, I was "afraid" of the big, confusing list of functions. Same for Java. AutoHotkey targets beginner programmers, so must be kept simple.

Balance between power and usability is delicate.
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005

Not sure what you mean by 45ers.


45 lines of code that fits maximised Notepad/Metapad! ..
Here: http://www.autohotke... ... 3616#83616
kWo4Lk1.png

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
2 People

If every contribution was automatically added, we would have a monster language

Does this discussion looks like "automatically added" ?


But I won't say that Chris as dictatorship over AHK. If that was the case, he would just have answered "No, this is wrong", and wouldn't have taken the trouble to set up a pool and reply here.

The difference between "No, this is wrong" and this, is that in first case you are rude mf, and Chris cares about people here at least so much to answer them politely if he has time. I never said he is dictator, however implications are the same. One pair of eyes can never see the whole truth.

Chris don't "denies to implement better support for low level api access", he just postpones such features.

I didn't got such picture. As I see it now, it is not certain that better low level support will ever be implemented. Also, if it comes after COM, we will have to wait years for it.

He is alone, cannot do everything, want to keep AutoHotkey small and not being a mammoth, including the documentation.

I always keep that in mind. I truly respect his work. However this is about something else. AHK is now bigger then any single individual, including Chris.

Creating fancy menues with big images is nice, but hardly a must have.

What is must have then ? You work in GUI don't you ? Lots of images and stuff like that. Why do we have TreeView, it is hardly must have, the same can be done in ListView. Why do we need URL control ? Its hardly must have ... Acctually, when you think more about that, anything is hardly must have. The truth is that menu command is obsolete, and that I can paste you here at least 10 topics from the moment I am here that ask for some kind of menu update. Also, the screenshot I send you isn't fency. U can't call something fency just becuase it has large icons - that was demonstration of possibilities. Icons are just one impovement over standard menus, there are at least 20 other things, including identifires for menu items, events like OnSelect, OnRightClick etc .... Next time, at least try to read what I send you before commenting publicly. Didn't I told you that you can say "No" and move on ? :roll: It is must better approach then spitting on somebodies work.... I am now sorry I PMed you for a help.

Controlling other applications is the main job of AHK, and Com is important for this.

When did I say the oposite?

But I believe you might want to push the language too hard. As you write, it is an automation language, not a full multi-purpose language.

I might push harder becasuse I care about the language future. I could care as low as bunch of "make me this script" people out there and do nothing but wasting your time. But I thought, "hej, this people are cool, and they do all that for nothing, so I am gonna help all I can". I don't think that my propositions to the language can be described as "pushing the language too hard". But you think about things you did in AutoHotKey. You can't say that GDIPlus will be used for automatition or that it is must have but still you do it, don't you...


This reminds me on "some animals are more equal then others" syndrome. I don't say that I am right, but then, I cant be so wrong all the time. At least some people deserve to be listened carefully - those that devoted themselves and work hard, like you, rajat, toralf, laszlo, goyyah, titan and some others. To put those people in the same basket as everybody else is a big mistake ...
Posted Image

PhiLho
  • Moderators
  • 6850 posts
  • Last active: Jan 02 2012 10:09 PM
  • Joined: 27 Dec 2005

Does this discussion looks like "automatically added" ?

I meant "automatic include of any added code", like public CVS access without moderator.

[fancy menues] What is must have then ? You work in GUI don't you ? Lots of images and stuff like that.

Sorry, I have hurt your feelings, I didn't meant that.
I don't feel that TreeView is mandatory either, I still haven't used it.
I am not fan of complex menues in GUI, at least because of a big problem in Windows, they disappear when a program steals the focus. I rarely use the Start menu. That's why I didn't dig in your code, but I certainly don't spit on it, and I respect your work.

You can't say that GDIPlus will be used for automatition or that it is must have but still you do it, don't you...

I did it, I didn't requested it to be in AHK. And people requested support to save images in clipboard or convert images. This can be useful in automation too.
I play with GUI and images, indeed, because AutoHotkey is flexible enough to allow this, and I like that.
I understand that's the same for you, and you are frustrated to hit the limits of the language.
OK, let's say I didn't wrote about fancy menues, I wrote a long message and didn't took time to reread it before posting.
Again, I am sorry.

Note that I value your input, and often support your requests. That's why I was annoyed that you announced you won't do wishes anymore. Perhaps I am just a bit more patient than you. ;-)
I chose this language (to work with Windows), and I stick to it, even if I am sometime frustrated by some limitation. But since I hardly do complex programs with it, I can live with it, while still trying to push it gently. :-)
Posted Image vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
I voted to leave as is since I think it would be better to promote users initializing variables rather than trying to modify the language and possibly create additional exceptions to add to the help file for unexpected behaviour. Also, I have a few scripts that use the current behaviour to test whether a variable has been initialized. This is unlikely to be typical usage though and could likely be coded differently if it is decided that this behaviour should be changed.

@majkinetor: Please don't stop making suggestions. Although I haven't agreed with most of your suggestions so far, I find many of your ideas ,and the resulting conversations, very interesting.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
My opinion on adding a Directive for this would be no as I think it would only add confusion. To me, this seems best as a decision left to the language developer where a decision is made and scripts should be written to deal with whatever behaviour exists.

Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005

My opinion on adding a Directive for this would be no as I think it would only add confusion.

Especially, if code is cut-and-pasted or included from another file. Such a directive must not be global, so after an included piece of code we have to be able to reset it to the value the rest of the code needs. AHK would have to keep track at each label, subroutine, and function the actual value of the directive.

Here is an example, where expressions are better returning the empty string, if a variable is unassigned:
NextAlmostPrime(d) {
   Static p1=2, p2=3, p3=5, p5=7, d1=6, d7=4, d11=2, d13=4, d17=2, d19=4, d23=6, d29=2
   Return d < 7 ? p%d% : ((m:=Mod(d,30)) ? d+d%m% : "")
}
This function returns the next "almost" prime number, when one is given as a parameter. It is used in integer factoring, to go through all the possible prime divisors. An example of its use is:
x = 1
Loop
   MsgBox % x := NextAlmostPrime(x)
It is an error if you call this function with a parameter, not almost prime, like 9 or 24. To detect this explicitly quite complicated expressions are needed, but with the current behavior the code refers to undefined static variables and returns the empty string automatically.

This might not be the script a beginner would write, but this propagation of empty strings through several layers of expressions helps finding bugs (misspelled variables, forgotten initializations or computation errors, like divide by 0). In another thread we learned that there is no chance to have exception handling even in AHK version 2, so this remains our only tool to catch some (short of breaking down expressions to simple ones and test the operands and results explicitly).

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I agree there are situations like your example where the sum of blank+number should more conveniently yield a blank result. I also agree that the current behavior helps catch errors in expressions.

However, it's inconvenient that variables must be explicitly initialized to zero rather than being left blank to achieve the same thing. When you mulitply that inconvenience times that thousands of times it occurs, it might outweigh the much smaller number of times when the current blank behavior is desired. In addition, the majority of weakly-typed languages seem to agree: they treat blank values as zero when involved in math operations (though some yield warnings when it happens).

I was originally not in favor of treating blanks as zero, which is why expressions behave as they do now. However, this conflicts with a key philosophy behind AutoHotkey: convenience. I never wanted AutoHotkey to be seen primarily as a programming language; that's why I feel it should continue to emphasize convenience and conciseness. However, no decision has been made yet. If it is decided to treat blanks as zero, the resulting loss of error detection may be alleviated by the plan in v2 to have better syntax checking. The most important syntax check will be the detection of misspelled variable names by warning when a variable is read but never written, and vice versa.

By the way, I apologize for the lack of exception handling. Maybe you feel it should be a higher priority than true arrays or even v2 itself. In any case, the pace of development is sharply limited because no developers other than Jonny have expressed any interest in being regular contributors to the project.