Forums Feature Suggestions about the scripting language

hello.
i just wanted to make some small suggestions on the current mirc scripting language, about things that bothered me while i was writing different sscripts:

i think it needs more restrictions, and maybe it could resemble a little bit more like C/C++ (or another programming language for that matter, as long as it's well defined, time tested and with as few errors as possible)
currently some things work no matter how you write them, for example:

• if a==b works as well as if (a==b)
  
• var %x = 10 works as %x = 10
  
• strings dont't have "-" surrounding them etc.
  

which is unacceptable. this could only confuse people and be the source for hard to find errors (if not in these examples, but there are more)

an option like: for (index=0; index < N; index++) would be nice.

anyway, the current language has worked for so many years so it cannot be said it isn't fine & reliable, but maybe some small improvements could be made, something that could make programming and error finding easier...

cheers, filip

I wouldn't want it to be more like C. I'm not in the mood to write stuff like
char* myvar = strconcat(tostring(atoi(readline(...)) + atoi(input()))," entries in list.\r\n")
instead of
%myvar = $calc($read(...) + $1) entries in list. (it's not working code, I know that)
C is old, a typed programming language instead of a scripting language, and it lacks too many required features (needing 12 includes and libraries to convert a number to a string and print it somewhere , and keep those header files out of mIRC please)


if ((((a==b)))) works in C, that's different ways too?

%x = 10 is NOT the same as var %x = 10, it's set %x 10, but with extra math operations

You're correct strings don't have "" around them (and the corresponding spaces problems) but you can just write /say hi there! instead of /say "Hi there!", and that's a simple string without identifiers and variables in it, for which you'd need some string concatenation operator.
The people for which the scripting language was developed don't know what a string is, and explaining that would be just as much a hassle to them. mIRCscript wasn't intended to be as elaborate as it is...


The for loop has been suggested before.

Agreed. I've done C and C++ and although I do like C++, I'd prefer to keep mIRC a scripting language and not a programming language. It is quick and easy and it's very easy to learn. That can't be said for C++.

Using parentheses in an IF statement is good to prevent errors, I agree. However, if programmers want to not to follow basic formatting to prevent possible errors, then that is their choice. Just like you can write a program all on a few lines or you can avoid using tabs to indent sections... it still works, but it isn't a good way to program because of the difficulty in finding problems. But, if people want to do that, that's their choice. Of course, mIRC is nice enough to format the tabs regardless if a programmer does it.

And, like Kelder said, the var isn't the same since var and set are local and global.

Quotes around a string are nice, but we've done just fine without them other than spacing issues as mentioned above.

And although the use of FOR is nice, we can do the same easily enough with a WHILE loop. Might take a little more code, but it works just fine. I still wouldn't mind seeing FOR appear someday.

- Removing the ability to skip the parentheses only serves to break a lot of old scripts. Now that's going to create a lot more confusion and hard to find errors then supporting optional parentheses. For those that are worried about whether a condition can work without parentheses, well they can simply use them in all cases.


- This is incorrect. Using var declares the variable as local, whereas simply using %x = <value> syntax will create a global variable if a local one with that name doesn't already exist. Not to mention that var can create multiple variables, while %x = <value> is considerably faster and can't be used from the command line. In other words there are many differences between these two ways of assigning variables.


- This is similar to your if suggestion, just on a much larger scale - it would break all existing scripts and completely change the language beyond recognition. Yes, it would make it much easier to remove the multiple consecutive spaces issue, but then again it would effectively erase the tens of thousands of scripts/addons/snippets that have been written in the last 10 years, would make a lot of people have to re-learn much of the scripting language, and would destroy the link between mIRC's langauge and IRC commands.

I certainly wouldn't call any of these changes 'small improvements'.

I normally say to people that have problems with these design issues to either live with them or move on to something else.
Not something that I really like doing though.


Maybe it's time that a new scripting engine was introduced to mIRC, such as TCL or similar.
I've no idea how easy or difficult this would be to implement into mIRC and I've no idea about the license that a language such as TCL is covered by. I'm sure there is at least one scripting langauge that would be suitable license and implementation wise.

Mirc could differentiate between the two scripting languages with the file suffix.


This might please the people who get upset because the following code does not evaluate the way they might think:



But since the mirc scripting language has no standard that says && has a higher precedence than || it's impossible to say if it's wrong or not.

Yet it would be simple to fix with some parenthesis.



I'd guess strings having to have quotes would make it easier to fix things like the above line too. Where “!1” is probably taken as a string.


Perhaps having two scripting languages would make it a bit more difficult for people in help channels and may divide the community a little.
But I think it's a good idea to help to keep users who notice these things that are not quite right yet.

Lua mayhaps?

This is pointless.
All that this is doing is making the language more like C++.
mIRC scripting was made to be simple, NOT complicated.
also, if you would change one of those 3 things, it would break most scripts and most people would have to learn the new syntax again.

I think that mIRC scripting is perfect the way it is, even tho there are some bugs, you can do that stuff in C++ and compile it into an DLL, and use it there.
or, you could even make a scripting language like that in a dll, and make it use that to parse different file extensions i.e: .scp files, if they are loaded.

Well, I only agree on the 'for' loop suggestion and your suggestion regarding strings to be placed in quotes. The for loop is a suggestion that has been regarded many times, who knows why it hasn't been added, but the quotes would be a pleasable feature. This could eliminate all of the problems with using the comma in identifier strings, such as:



Would be nice to see this, but quite frankly, mIRC would have to remain backward-compatible with the alternative method, providing the capabilities of old scripts to still 'have a chance' at running. Who knows, maybe this is possible?

Guessing the reason I would say its becuase its not needed, anything you want to do with a for can be done with a while, so maybe its just why build a new wheel when theres a spare already in the boot?

Just thinking about those for loops again;

Maybe it would be possible to make them a little faster than while loops as the end loop event could be cached and just parsed once, for example.

It would be nice to have some other method of doing something like

var %x = 0
while (%x < 10) {
echo -a Something
inc %x
}

Maybe it would be nice if Khaled made it possible to do something like:

.echo -q $loop(10,echo -a Something)

Which I would think would be easy to write and would be a good bit faster than a while () loop.

Just a thought.

I don't know about anyone else, but most of the time when I have a loop, I've got multiple lines in the loop, not something like a singe echo statement.

Another Example:

.echo -q $loop(100, myAlias)

$chr(44) isn't difficult to type when you need a comma in text.

Having a FOR loop wouldn't be bad, but it really isn't necessary. As mentioned, the WHILE loop works just fine. At most, you'd save two lines (the /set [/var] and the /inc lines).

personally i agree with the first post, this programming language is becoming a little chaotic, restrictions are needed and ambiguities eliminated.
improvements are necessary, as evolutions is for human kind
old scripts are for old versions, and besides, they can be updated quite easly.

Think of it this way...

If we made it so that strings required quotes, scripts *could* be updated... but many won't be. Many people use scripts that they like to use and if those scripts aren't updated, they will stick to using old versions of mIRC. From Khaled's point of view, I doubt he wants to make new versions of mIRC that many people won't use because of incompatibility with the scripts they want to use. Yes, we lose a few scripts here and there as mIRC versions increase, but doing the strings in quotes will break virtually all scripts that use strings.

I think what would be better is to do something like you see in other languages...

Input:
echo -a $gettok(If you want to see a comma\, then use a comma,1,44)
Output:
If you want to see a comma

Using a \ before it means to display a comma and not treat it as a deliminator. Doing something like that would make a LOT more sense that requiring quotes...and if you don't like using \, you could use another character or even a couple characters... \\ or whatever. (Obviously, the \ would not really be part of the string.)

Quoted strings just wouldn't fit IRC. Would you want to have to do /me "does an action" or /join "#chan" or /msg "nick" "text" or anything like that all the time? (and I'm not talking about in script.. I mean at the command line, which is what script is based on) The scripting language evolved from those simple irc commands, so there's a good reason for not quoting strings... It is a chat program after all, and you don't usually need to send binary data in text-based chat, so why not treat everything as a string? Changing the basic commands that everyone already uses would be a huge headache for new and experienced users alike. If you don't like the scripting language, don't use it. Write a dll or something instead. No reason to make thousands of scripts obsolete just to turn mIRC script into something that it's not. mIRC script is a scripting language, not a programming language. The sooner people realize that, the sooner they may stop complaining about it being different from what they already know.

As for for loops, I don't see why not... There are usually 3 or 4 different ways to do any one task in mIRC script anyway; can't hurt to add another looping method. On the other hand, we already have at least 2 ways to create a loop (while and goto) so why should Khaled work to add another way to do the same thing instead of taking that time and adding something truely new and useful?

Btw, one last comment on the whole idea of using quotes around a string to prevent problems with commas or problems with spaces... what about when you WANT a quotation mark in your string? You're still stuck with a problem.

Indeed reminds me of all the hazzards with JavaScript

Definetely agree with this. In my honest opinion, I don't think that the language needs any real changes to the syntax or structure upon what is currently available. New features, whatever, but backward compatibility is a serious issue, so I'd say no to changing an easy syntax that would basically corrupt all previous routines.

*cough* //echo -a "Would require quotes, but if I wanted a \"quote\" in my text, I'd need \\these\\ :-D"

heh, hilarious and overdone; not really 'saving' any time at all.

What's worse, "//echo" and "-a" are strings too, so, depending on how it's implemented

"//echo -a Would require quotes, but if I wanted a \"quote\" in my text, I'd need \\these\\ :-D"
Each line is a string containing a command -> to parse the command you still lose the spaces?

or
// "echo" "-a Would require quotes, but if I wanted a \"quote\" in my text, I'd need \\these\\ :-D"
Each line is a command string followed by an arguments string -> $1 is still the first word, $2 the second, $1-2 is still word1-onespace-word2...

or
//"echo" "-a" "Would require quotes, but if I wanted a \"quote\" in my text, I'd need \\these\\ :-D"
Each line is a list of strings, the first contains the commands, each next one contains a parameter -> $1 = "-a", $2 = "Would require quotes, but if I wanted a \"quote\" in my text, I'd need \\these\\ :-D" This seems to work ok, but if you want to use $4 to mean the 4th word, you'll have to do a $gettok yourself, or hope the caller used /customalias "word1" "word2" " spa ces " "word4" "word5".

And then we can start using %vars and $identifiers (say last type)

"var" "%cmd" "=" "echo \"-a Hi, \" $+ $nick $+ \"!\""
%cmd $+ " How are you doing?"
Will this execute the command "echo \"-a Hi, \" $+ $nick $+ \"!\"" with one parameter? Should we add extra quotes in the quoted command? Should we force a second evaluation of that string? ...

Just think about it...

Hell no :-D

C++ seems to have no problem with these
string could be at least inserted optional, so that we'd write the sentence 'mary goes, to school?' 2 ways:

or

which is easier?
i don't really know what chr's are for blank spaces and quotation mark, so i wrote 60 and 999 randomly....

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. However, I have sometimes thought quoted strings would be advantageous.

How about a compatability mode (set to not accomodate quoted strings by default) that loads an alternative script file line parser? It could be set by the first line of a script file containing "quotes on" or some other means to identify only that file.

Any thoughts?

I'm not sure that I would agree to using multiple parsers. That would just cause confusion.

Confusion to whom? Surely the person writing the script would know whether they set it on or not. And I think that if they set it on once, they would do that for all scripts they write in the future and be accustomed to writing with quoted strings.

If you mean it could cause confusion when asking for help, there is that possibility. But I expect anyone who specifically set the quoted string on would normally know enough to mention that in any help request.

If I haven't covered what you meant, please explain.

You know, I think Perl might be pretty well suited.

The String interpolation removes the need for concatenation of variables to strings, as you embed them in the string, like:



There are many other useful constructs. I also think that being able ot embed comments is something mIRC script lacks. Perl also has native support for RegEx, which is more powerful than the flavor in mIRC script.

The only question is how impliment. If you ask me, you can bundle a stripped version of the win32 activestate perl interpreter, like without some of the non essential libraries ( but maybe check if the system already has Perl, and if so, ask the user if they want to use it instead.)

I know this might be a long shot, but I think the sheer power of Perl and ease of use (once you learn how Perl works, you can do some really cool things in a very small amount of lines in most cases.)

IMHO, I think its worth looking at. After using Perl as the host language for ASP (yep, asp without vbscript or javascript!) on Apache::ASP, it just made things so much easier. You no longer need so much extra code to do realatively simple tasks.

Perl has lotsa possibilities with variables etc, but imo that makes it somewhat its problem. It's too overwhelming, too many different approaches, too easy to write code no-one with less than 4 years of Perl programming experience is going to understand. Makes it difficult too if you read the code you wrote yesterday and don't have those 4 years of experience yet

That said, I do like Perl, I've even written some irc scripts in Perl (irssi uses Perl as its scripting language) and they actually worked eventually. You can do way more with Perl (threads!), but the learning curve is a lot steeper too than that of mIRC script.

So, here's a feature suggestion: bring out mIRC 7.0 with the possibility to run Perl scripts

That'd be great, I'm still new to perl and all, but I'd really like to see mIRC compatable with perl scripts.

*waits for mIRC v7.0*

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

I'll try to explain my point somewhat better. Yes, I was exaggerating, no I would not want to put that many quotes, but I was making a point that the mIRC script is unique in that you can create the line of code to execute on the fly with all kinds of $iif, $identififers, %vars, $+, evaluation changing like [ ] and $eval() and it's all text...

set %blub blah blah
The above is a nice command with 2 parameters (a %var and the new value) but it's also all text, since you can do
echo set %blub blah blah
which is a command with a single parameter. You can even do
$iif($?,echo,set) %blub blah blah
What is text, what is command, what should be put in quotes?
hadd -m somehash command $iif($?,echo,set) %blub blah blah
This one is simple, 1 command, one switch, 3 parameters (table, item, value)
$hget(somehash,command) another blah
Uh oh...

So, how would you get around to do this MaxScript (I've never used it) style syntax using quotes on the above examples? If you can give a set of nice rules to put in quotes and allow for multiple spaces, I'd be happy to read it and find more complex examples If you can fix those too without changing your rules, I'm probably all in favor of your syntax suggestion. Note that /me <text> is also used from channel windows, so keep the effects to end-users (not scripts) in mind too

Heya,

Thanks for the reply - The 'My Home' page didn't show there was a new post - hmpf!

I'll quotify your examples. However, keep in mind that I'm bending the rules a bit with the "if it only accepts/returns one parameter, you don't need quotes" bit. This is entirely for user convenience a la the "/me does something" thing, as opposed to '/me "does something"', which would be annoying indeed.
set %blub blah blah
There's two parameters, but the first parameter can never have spaces anyway - variable names cannot contain spaces. So the above should already work.

echo set %blub blah blah
As you mentioned - indeed, this is a command with a single parameter (and optional flags). So, the above should work as is as well.

$iif($?,echo,set) %blub blah blah
This shouldn't require modification either.
There's three bits to the $iif
- the comparison, which is separate, and I think I illustrated in my post
- the value to return if true - note: value, not values. -unless- this value contains a comma, you wouldn't necessarily need to put quotes around it
- the value to return if false - same as above

The rest of the line is just the parameters passed to echo / set, namely either a single parameter - or two parameters, the variable, and then the rest.

You might thing that problems here begin to creep up if you were to do something like this:
echo $iif($?,$me rules!,$me sucks!)
Would it still echo <your nickname> rules!|sucks! ?
MaxScript doesn't have a construct such as $iif, so I can't draw a direct comparison (nor would I always want to).
However, I would imagine it would have to be re-formulated as such :
echo $iif($?,$me + " rules!",$me + " sucks!")

However, if you were to do in-place replacement of variables, much like say NSIS, you would simply keep things as they were.
Or, if you wanted to type strongly:
echo $iif($?,"$me rules!","$me sucks!")

Note that in-place replacement would also facilitate things like:
/say Hi, $nick!
Without the need for the $+

However, that would probably be a far greater change to a parser.

hadd -m somehash command $iif($?,echo,set) %blub blah blah
Again, should already work

Just to deconstruct... you've essentially got this:

var %func = $iif($?,echo,set)
var %cmd = %func %blub blah blah
hadd -m somehash command %cmd

No quoting necessary, that I can tell. But let's say I wasn't bending the rule a bit for convenience. Then it woud be...

var %func = $iif($?,"echo","set")
var %cmd = %func + "%blub blah blah"
hadd -m somehash command %cmd


What if you don't want to literally store %blub, but the value thereof ? Well, this :
var %cmd = %func + " " + %blub + " blah blah"
( Again, in-place replacement would simplify the above - it'd just be : var %cmd = "%func %blub blah blah". However, what if you then -did- want the literal %blub ? You'd have to escape the % sign, probably. Cost/Benefit )

I'm not too actively trying to lay out rules, by the way - I just think it can be done. Quoting strings can already be done - other languages show this. Making convenience exceptions should also be doable, and I think the "1 parameter" decision lends itself best to this.
The real breaker would be if there is a command that accepts multile parameters, that can -also- have spaces in them. I don't think any exist - that would basically be a command a la :
/hw Mostly Water Gnat Swatting
Which acccepts two parameters, each consisting of a string with exactly 1 space in them (i.e. 2 words) - no more, no less (at least no less for the first parameter).
The output of said function being:
Hello world of Mostly Water. Welcome your Gnat Swatting overlords!
So if you were to have such a command, then yes.. you would still be forced to do this instead:
/hw "Mostly Water" "Gnat Swatting"
Which I think is probably a Good Thing(tm)

Also, again, the end-decision is entirely up to Khaled For all I know the changes would be far more extensive than I can imagine, and he would rather just drop mIRC script altogether and implement Python, or interface with the WSH.

By all means, though, keep coming up with possible breakers - if nothing else, it'll make me use my brain some more

Happy Holidays, everybody!