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...