Forums Feature Suggestions about the scripting language

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!