Forums Feature Suggestions Local aliases

It likely will have some impact, but the way I envision it, and of course I've never actually seen the mIRC code so I could be completely wrong, it should only have an impact if you actually make use of it. Meaning I see it as something like this:
if (has_local_aliases) {
all the stuff to handle it
}

meaning if you're not using it, there really should only be 1 if check, and that if check would be to determine if there are local aliases defined. The way I see it, it would just sorta have the be an extension of the alias -l. Meaning what I assume alias -l does is (internally) translates say alias -l blah into something like script1.mrc.blah meaning it keeps track of which ones are in which file. So for nested aliases it would just do something like script1.mrc.theparent.thenestedalias or something along those lines.

Oh and furthermore about your very CPU intensive script. I'm personally someone who believes such things are not what mIRC scripting is designed for. The way I see it, mIRC scripting was designed more for stuff like flood protection and auto identifiers, and things of that nature. Not, picwin GUI, 3d libraries, games, etc. While it can do those things, I personally feel that those things should not take precedence over the more common scripts simply because to a huge script 1ns might make a signifigant difference.

Of course the issue of what kind of impact it would have could easily be rectified if Khaled would comment on this. However, since he's never really made any comments on language extensions before, I doubt that will happen.

I really want Khaled to comment on this parser issue, I can't understand why "the parser would be <slower|faster>!" is always presented as a fact, no one here has even read the damn parser AFAIK. Until then, to me, regardless of the knowledge of anyone, these "arguments" are just guesses.

Edit: I mean, come on, since Khaled seems to be the only one who has access to the parser code, this analysis is up to him as well! All we have are our silly mIRC-executed benchmarks, which use the parser itself already.

I totally agree, however I've seen at least 5-10 posts where "the parser would be slower" was brought up, and people asked Khaled to comment, yet he never did. For whatever reason, if Khaled is asked a question on these forums, 99 out of 100 times he refuses to answer.

Well, there is this one post where Khaled stated the addition of a CASE statement would be slower than existing methods "since it would require more parsing". Though, for fairness sake, Khaled hasn't indicated that adding slowness to the script parser will automaticly rule out the addition of said feature (though I'm sure it's still considered).

(cold): You are correct, only Khaled has direct access to the mIRC source. However, even without the source many of us here are intimately familiar with how mIRC works inside and out... both on the surface and behind the scenes. You may have noticed many posts where we've logically deduced and narrowed down the exact cause of a bug, and in some cases pointed out exactly how Khaled ought to fix it. Granted, I've never seen a line of code that Khaled sees, but contrary to what codemastr might tell you, I'm not clueless when it comes to programming and I can easily anticipate what approach and oversights people have made (and will make). It's not difficult to wrap your mind around a scripting engine that you've used every day for the last 5 years.

- Raccoon

Yes he said that, but he really didn't given any indication on how much slower it would be. Meaning the way I see mIRC's parser is something like a table:

{ "while", handle_while_function },
{ "if", handle_if_function },

etc. And each time mIRC encounters something in the file, it searches that table. So the way I see it, adding { "switch", handle_switch_function } would only mean one more comparison. And that's assuming Khaled does a linear search, if the table is sorted, then he can do a binary search which would mean that adding a switch would really mean a speed difference that is so small, it really isn't even measurable. But again, only Khaled can say for sure how it works, and for whatever reason he refuses to do so. Personally though, I don't see local aliases being much slower than local variables. For the most part, the logic would be the same. To simplify it even more he could make a new "command" instead of doing alias -l you do alias -a { ... } or something so that it can easily be deduced that it is a local alias. Like I said, I'm sure it will have some speed hit, but I don't think it will be large enough for anyone to notice.

Although it's a little different, it kind of reminds me of the idea I once had for GOSUB/RETURN in mIRC (old board), providing the ability to call subroutines within functions cleanly and effeciently, ofcourse most people opposed that. They said it was "useless", and "Just use an alias", and "An alias IS a subroutine" (). Since then nothing like it has been added.

I support your suggestion, but would like the syntax a little different, not using the word 'alias' as it looks weird inside an alias, perhaps 'sub' or something.

But then you remove the ability of true nestedness (or at least introduce the same confusion):



Meaning, what if I want to have an alias that is local to the local alias?

I see what you mean. A question though, How would you want local variables to act in nested aliases like that? If the variable was defined in the main part ('parent') of the alias, should it be available to the sub routines? If a nested alias defines a local variable, should the parent alias and all other child alias be able to access it?

(Please don't think this is specifically directed to you, it's more like a good old rant being spitted(is this correct, "spitted"?))

I know what you're talking about, I even agree, since I often see myself being familiar with it as well. What I'm saying is that this experience is not sufficient to bring up any solid argument about such a system, which one may surely have valid thoughts about, based on what he sees from the results he gets, but still, he doesn't *know*, he didn't *read*, he didn't *code*; he just goes by trials, errors and consequent guesses.

IMO, the "parser" subject and others fall into the above category no matter what, regardless of any deduction anyone brings, whether it seems very reasonable or not. I'm not underestimating your programming knowledge, nor any capacities you may have, but it's all into the "guesses" category. Therefore, for me it seems useless to bring into discussion the unknown mechanisms (again: familiar, similar, predictable at some point, but not always - they're *unknown*) available on mIRC. They're just out of our context, I think Khaled is the one who should even consider their functionality and further downsides.

I mean, everytime someone suggests a non-bloated feature that somehow goes against the current parsing logic we see in mIRC, the whole issue about it <being slower|giving much work|having this and these downsides> appears. Based on what, our benchmarks? On the current performance? On *experience*? How could one <measure|predict> the performance of such a feature if he doesn't know how it would be put along with the huge mIRC source code, tested, developed, organized? He doesn't really know how major things really fit into each other, so what's the point of "stealing" them to his argument which says "this feature shouldn't be added because the parser would suffer"?

Well I'm tired of thinking right now; my straight conclusion for the moment is that, IMHO, instead of virtually messing with mechanisms which functionality we could imagine from our experience, and then going to nowhere with what we see in them, when the subject is actually *suggesting features*, we could just develop our ideas and opinions with arguments we're really fully certain of, and deliver them with all the apparent limits to be analyzed and filtered by the proper person (the author, of course).
And if anyone says "that's just giving more work to K", omg, we (me, at least) can perfectly see he manages his priorities already.

(End of rant, sorry if anything)

That's true but also the point here. If you hear me saying "this isn't worth Khaled's work" it's not because I feel sympathy for the hard work he does, it's because of the priorities you mentioned: there are hundreds of feature suggestions and only a few of them are actually implemented. So if 10 things out of 100 are going to be added, I want the ones *I* like to be in that 10, not others that I consider less useful (for both the majority and me). The amount of work Khaled has doesn't concern me, I'd just prefer his coding weekend spent on adding passive dcc support for everybody and not on implementing aliases within aliases (two recent examples that came to mind)

You got a point there, priorities. I was more focused on the "oh more work, poor K!" thought.. but yeah, I agree with you when the thing is to agree or not with a suggestion. You actually aren't using any argument like what I described above, you clearly assume it's your opinion (at least this is how I read it), instead of taking the suggestion alone and saying "oh I don't like this suggestion, the parser will become awfully slower".

If I'm not that clear, please wait until tomorrow or something. :tongue:
/me goes to sleep after 2 days awaken by force..

..at the same time, I disagree when you mention another suggestions you find more important when we're not talking about to-do priorities.. we're just listing ideas on this forum, it's not that they should be added tomorrow. Just a thought I forgot about. Not that you did this, but people do this, like if everything being asked was part of a big racing championship.

Now I'm going :tongue: *addicted*

You should also expect strong opinions when people make, often not very well-planned, suggestions that will significantly change the existing language as we know it, one way or another.

I often see the suggestion that all strings and values should be quoted and then we wont have a "space   problem". This is fine and good, except it would completly change mIRC scripting as we know it, require Khaled to completely rewrite everything, and make so many scripting methods suddenly impossible. I'm also happy with mIRC as it is, and dont feel it should be more like C or more like Perl or <insert language of choice>, so when people suggest things like FOR loops I tell them to get bent and deal with WHILE because this is mIRC Script. (oh poo, I have to inc %i now)

I agree though. Perhaps instead of over analizing people's feature suggestions... no matter how wrong or impractical or impossible or plain ludicrous they are, we should just let them be and only reply with constructive critisim if we like the idea. Focus our attention by posting replies to feature suggestions we would like to see (like all of mine. :), and ignore those we don't care for.

- Raccoon
(grammar malfunctioning today)

I agree that this forum is about freely giving new ideas, I don't have a problem with that. Nor would I ever say "stop suggesting stuff people, there are already more important things to be added" or anything like that. The average user who comes and suggests something doesn't (and has absolutely no obligation to) care about the relative usefulness of the suggestion or the size of Khaled's to-do list etc.

But exactly because many of us have been around enough to know that the to-do list is big and that with each version only a few of the tons of suggested features are added, priority should matter to us. That's what my first post on this thread was about: by deeming this feature "very useful", we automatically give it greater priority and that *could* affect its relative position on Khaled's to-do list. In practice, this *could* mean that the next version might have aliases-within-aliases (which I don't consider important) but still no passive dcc support (which I do). Of course, I don't think that adding the 1st feature would necessarily cause the 2nd one to be neglected, but if there's even a small chance for something like this to happen, I think that I should do the only thing I can to prevent it: say what I think about it.

Personally, I hate the way mIRC's local variables work. If it were up to me they'd work like most language. Meaning if I do:

alias blah {
if ($1) {
var %i = 1
}
}

Well then %i only works from within that if statement. The other thing is that variables defined within a larger block can be accessed within smaller blocks, i.e. if var %i = 1 was within the alias { } it could be used within the if() {}.

That should answer your question, for the first part, local variables of the parent should be available in the child (and grandchildren,etc.) and a variable defined in the local alias should only be available within that local alias and it's children (and grandchildren, etc.). But, like I said, if it were up to me the entire local variable system would work like that.