AutoHotkey Community

No. No changes would need to be made for concatenation if the current use of the dot character for concatenation is kept in place, unless there's something I haven't considered... With spaces would work for concatenation and without would be for dot notation... Not too difficult to remember or distinguish. Also, it makes more sense to plan ahead for the possibility of structs, etc.. now instead of purposely making changes that would need to be changed and break scripts later, unless Chris says that they will not be added. If Chris doesn't plan on ever implementing functionality that uses dot notation then what you are suggesting wouldn't conflict with potential future plans for AutoHotkey. No. I don't see your point an you are obviously misunderstanding what I am saying. Leaving something in place that currently works well is hardly lazy language design. It's more "if it's not broken then why try and fix it?". To clarify what I'm trying to say in response to the reasons you have given so far: I feel that the existing functionality serves it purpose and functions well. I don't see the need for a change here. These are the reasons that you have given to support what you are suggesting so far (please correct me if I've left something out):

- you like the idea of not having to add spaces for concatenation (personal taste)
- you don't care for dot notation so AutoHotkey shouldn't reserve syntax for this functionality (personal taste)
- you think all operators shouldn't have a space around them even though this operator has already been designed and is currently used this way(personal taste)

Have you given a reason of how this would benefit AutoHotkey in some way other than your preference of how you'd like to look at the code?


No. I consider it to be the biggest thing that should be taken into consideration that would be affected by the change you are suggesting.

I don't see a mistake therefore I don't see a need for correction here. That and the other reasons I've mentioned sounds like a good reason for a poll. The reason that I suggested that you start one is that you are the one that seems to think that a change is required to the methods currently in use. I have been explaining why I don't agree with the change you are suggesting.

That's not an operator, but the comment sign requires spaces too...

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Um... yes, the ternary operator is an operator. It's a predefined set of symbols that takes the arguments passed to it and performs an operation on them. The fact that it takes three arguments instead of two is not a fundamental difference in form.

However, the comment symbol is not an operator. It's just a directive to the compiler or interpreter to ignore the line or block denoted by the comment symbols. It requires a space in AutoHotkey only to accomodate naked literal strings.

I wont even read this discussion, jonny

_________________

My syntax was probably wrong. I just wanted to point out that, beside the fact it is not an operator, the comment sign is another example of required space. I wasn't contesting that the ternary operator is an operator!
There are other examples of syntax requiring spaces or lack of spaces in the syntax, anyway.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Sorry, I misunderstood you.



Yes, for the syntax in general, just as with C where spaces and newlines aren't an option in certain places. However, I was speaking only of expressions. Spaces should only be required around keywords that could otherwise be a part of a variable name, like 'and' and 'not'.

Yes, though it might be a long time and/or get implemented by someone else (assuming it even happens).

It would depend on code size/complexity, documentation complexity, and how well the feature fits in with the philosophy/style of AutoHotkey. Also, I'd want it done as completely as possible to minimize the need for future enhancements that would break scripts. For example, structs should be passable to functions, and perhaps returnable from them as well. Perhaps DllCall and ByRef should be supported, etc. Also, the performance and memory impact should be considered since this type of feature might impact all scripts, even those that don't use structs.

Probably yes, but only where it's not ambiguous such as var."string" (I think PHP is this way too, but I'm not sure). Also, we could consider changing the concatenation operator to some other symbol such as "..", but that might have a lower benefit/cost score than the current dot-with-spaces method.

Thanks for the responses Do you have a suggestion for a character and/or method that wouldn't conflict with dot notation? It's probably more a matter of taste but I would prefer to force the use of space characters instead of having to remember special exceptions where spaces would need to be used.

No, PHP uses the dot only for concatenation, so there is no exceptions or special rules. I agree with corrupt, don't make context sensitive rules!

I'm inclined to leave the concatenation operator as it is now because changing it to ".." or some other symbol "just in case" we ever have structs seems like it would do more harm than good.

Does "as it is now" include the required spaces? It wouldn't break anything to switch to a more lenient syntax.

In general, lenient = exceptions = potential for confusion, future conflicts...

Yes, the spaces are deliberately required to hold open the possibility of structs. However, I realize that using "." for both concat and structs might be too confusing compared to alternatives such as using "->" for structs or switching to ".." for concat.

I vote for ".."

_________________

I still like it better the way it is currently but .. sounds ok...