Just re-opening this dead thread
I can see why there would be some problems with regards to making mIRC's syntax work different with regards to spaces. E.g. it handles the parameters based on spaces.
However, so do a lot of languages. MaxScript, for example, takes parameters delimited by spaces.
fn doSomething parm1 parm2 parm3 = (
-- whatever
)
doSomething "Hello World" "of" "wonders."
And the above immediately shows that quotes are required around strings. This is common sense in most other languages.
Riamus explained that for identifiers where strings with a comma kill the identifier (as identifiers separate by comma.) that commas could be escaped. That's very odd as, again, just encapsulating the string into quotation marks should have mIRC realize that any comma within is part of the string, and not a parameter delimeter.
Hrung mentioned:
'Would you want to have to do /me "does an action"'.
No, of course not. However, why should you have to do that ? Let's keep in mind that there are many commands that only accept/return, essentially, a single parameter. /me accepts only a single string. But this doesn't have to be typed strongly - it would be perfectly fine to assume that anything after /me (short of command delimiters (defaut "|", and you have to use //me)) is the single parameter string that should be parsed. So
/me does an action
Would still work perfectly fine. Similarly, var %file $findfile(c:\,hello*,1) where the file to be found is "Hello__world.txt" (where the underscores should be spaces) is only expected to return a single string; %file would be "Hello __world.txt", rather than the current 'Hello world.txt' (Essentially two strings)
Also similar if you were to do comparisons... if (%var == "whatever the heck") and if (%var == whatever the heck) could be treated as equals as, again, the comparison is only to a single element string. When you do if (%var == whatever the heck), you aren't comparing three bits of string against another three bits of string. (Though in the current mIRC script parser, perhaps that is exactly what is going on behind the scenes.)
Riamus2 then mentioned:
"what about when you WANT a quotation mark in your string? You're still stuck with a problem."
Yes, but it would be a probem that coders in practically all other languages would be familiar with. Escaping of quote characters is the norm, not the exception. Escaping spaces or escaping commas would be.
Kelder then went on to put quotation marks around everything - I'm not sure if they were being serious. Their last line :
"var" "%cmd" "=" "echo \"-a Hi, \" $+ $nick $+ \"!\""
%cmd $+ " How are you doing?"
is ridiculous, as that's not how it is in any other language. Assuming, once more, that a variable can be assigned only a single parameter*, and that echo would fully understand that -a is a flag, not part of the string (it does now - why would it be any different if redesigned?)
var %cmd = echo -a Hi, $+ $nick $+ !
%cmd $+ How are you doing?
No different from how it is now.
* unfortunately, in mIRC, var does multiple assignments of values to multiple variables. E.g. the help example:
/var %x = hello, %y, %z = $me
This leads to a problem if you don't strongly type, e.g.
/var %x = hello, my friend!, %y, %z = $me
But wouldn't if you typed strongly:
/var %x = "hello, my friend!", %y, %z = $me
Note that the $me still didn't require any quotes as it doesn't need strong typing. If there was a possibility that it would have a comma, you would want to type it strongle. That said, it seems much safer (and only marginally more typing) to me to do:
/var %x = hello, my friend | var %y | var %z = %me
It also reads more clearly (in my humble opinion)
BrunoJ then wrote:
"I agree that quoted strings should not be the default. There is no way I want to rewrite my 7000 lines of script just to accommodate it."
I would first question whether you indeed have 7000 lines of strings that you would all have to change. Second, and more importantly, there have been code changes in mIRC in the past that required scripts to be gone over and adjusted where needed to make things compatible once more - and it was then up to the author whether to offer/support only this new version, both versions, or not bother with a new version.
I'll get back on this topic in a bit.
BrunoJ then continued:
"How about a compatability mode"
Certainly that seems like a reasonable-ish solution to me. However, the proposed method of indicating this in the first line seems iffy at best, as that is part of the editing scope. Instead, perhaps, a different file extension could be used to identify scripts for the new scripting engine. ".mr2" or whatever.
Multiple parsers might lead to confusion with those very new to scripting. However, if a all possible, those new to scripting should not be introduced to the older scripting engine at all - unless they would specifically want to author for the older engine. This way, those new to scripting, would jump right into the way the new engine would work and there shouldn't be any confusion.
On the side of the end-user there shouldn't be any confusion at all - installing scripts should lead to expected results, regardless.
A more significant consideration is whether Khaled would want to include and support two parsers to begin with. Of course, assuming he would want to write a new parser to begin with
To get back on the topic of scripts going kaputt. As I mentioned, that has happened before, and either authors checked their scripts to see whether they were affected - and fixed them, or not. I see no reason why that would have to be different now.
Granted, the ramifications would be more widespread - the vast majority of the scripts out there use strings. In this I see a role for scripting resource sites. It should be entirely possible to allow -anybody- to edit a script and upload the compatible version for download, so that if an author doesn't feel like doing it, the community could do it. You might wonder about letting others touch people's code - perhaps they would introduce naughty code. I think the solution to that is fairly simple as well - as the only changes required should involve quotation marks and the odd backslash to escape quotation marks, any changes to a script -beyond- those (and perhaps comment lines, whitespace) could be flagged and the adjusted script rejected.
All in all, I think the ramifications may be widespread, but something that can't be overcome - while the scripting language itself would improve, the consecutive spaces issue would be a thing of the past, commas in strings for identifiers issue would be a thing of the past, etc.
The only thing is... is Khaled willing to do this ? I wouldn't blame him if he doesn't want to - I'd have to pay a good deal more than the registration price if I had to pay a coder to make such changes. So the above is just my stance on this.
I, for one, do request this type of change to the scripting language be made. But that is all it is - a request
