Forums Feature Suggestions Local aliases

I think this would be nice to allow aliases to be used inside an alias. For example, instead of this:



We could have this:



In that situation, this shorten the code a little bit.. maybe we could say it's useless. But there's a lot of other situations in which that could be faster and could make the code easier to understand.

Yea, pretty useless.

Next we'll want locally-local variables specific to the locally-local alias.

There's really no need to nest something like this. There really isn't.

Well, actually this could be a beggining of objet oriented programming, it would be pretty usefull

Yeah, great idea

I like the idea. I think it could be very useful.

Now what about the evaluation of parameters? Assuming 'alias' will be treated as a command here, should it evaluate the parameters being passed to it or just leave them 'as is', except maybe the pipe separator?

If the developer chooses the first option, it will be such a pain to write those aliases, endlessly calculating how would they look after getting "compiled".

And if he chooses the other way, how would we build a static alias out of dynamically stored commands?

Umm... what in the hell are you talking about? It would work just like any other alias, except local to a function.

Right, but here alias will be a command name and not a remote prefix, that's why it's important not to evaluate the parameters following it.

Not all commands are evaluated immediately. Otherwise, /set would never be able to get the variable name.

I've yet to hear a good reason why this would be very useful ("very" as in "useful enough to consume a part of Khaled's precious time in developing mirc"). The only use I can see is having shorter names for aliases. Meaning that this feature would allow single letter aliases of the same name, like this:as opposed to the current way:
I don't even consider saving letters necessarily good because it could lead to less descriptive alias names (if the aliases foo and bar were huge and each of them used a bunch of $i()'s, don't you think that this could cause some confusion as to what $i() does?)

Do you think saving a few letters from alias names is "very" useful or do you have a better use in mind? Oh and before you mention something like "other languages support that", I don't find this argument strong enough. We're talking about mirc, which means we should take into consideration the nature of the mirc scripting language, the development status (one-man project) as well as the scripters base.

That is a great idea

qwerty:
Well, your example is an use of the suggested feature, but I could simply want it to organize many parts of my code.

General reply:
Is this really worth it? I mean, I think it's a good idea and would use it a lot, but do we need it? We don't. Maybe many wouldn't get even close to "need" it.
But I believe that anyone who answered this question would also point a lot of features that aren't really needed, but improve a job, and I think the same point could be applied here.

For example, /var sets local variables, but we could use the undocumented /set -l or the documented /set -u. Granted, /var accepts a list of local variables, but since it isn't capable of setting a list of global variables as well, I assume it's prior feature is setting local variables. So it's an improvement, but not really needed.

I know this suggestion is much less needed when comparing to /var's improvement, but it still improves something, even if a little. And maybe it could bring room to more improvement in the future.

So, IMO, its value/worth only depends on its difficulty to be developed by Khaled.

Online:
It wouldn't necessarily need to be declared with "alias". It could be "lalias", "local", "whatever", then from that point the given name would prior the feature. Meaning you couldn't have an alias called "local" or "whatever" (that could still break some scripts, but ctrl+f+replace would be the finest solution) and also that the parser would treat it differently. I don't know the consequences of this, if it'd slow down parsing etc. but then again only Khaled could know and decide if it's worth it.

Ok, I started out writing a post giving a small case study of different implementations of this. Half way through, I realized how stupid it was.

My conclusion: aliases within aliases is useless, and would only serve to complicate the language without giving any improvement. This is based on both the "aliases within aliases as a quasi class-and-method implementation" and the "aliases within aliases as just that" implementation.

It's just useless. Sorry.

And your arguments are...? Sorry, I'd like to know.

My arguments for not introducing such a feature in mIRC is that 1) it's useless (as stated in my previous post) and 2) it will complicate the code unecessarely (also mentioned in my previous post), not to mention the parser speed setbacks.

I was asking about being useless and complicating. Many features could be considered "useless" by one and they're still added. I don't get why should it be different now. I also don't get how could it complicate the code. I get, though, the parser issue, but again I think this is up to Khaled.

Useless? Well then let me ask, why is your suggestion of constants so much more "useful"? alias -l someconst { return somevalue } would emulate a constant rather nicely. So why is your suggestion so much better?

How will it complicate code? I see it simplifying code. Instead of having, for example:

alias output_notice { echo -t @notices $1- }
alias output_msg { echo -t @msgs $1- }

alias my_notice {
.output_notice $1-
}

alias my_msg {
.output_msg $1-
}

where as with local aliases:
alias my_notice {
alias -l output { .echo -t @notices $1- }
.output $1-
}

alias my_msg {
alias -l output { .echo -t @msgs $1- }
.putput $1-
}

Now thats not the greatest example, but it shows the point. You no longer have to have super descriptive alias names or things like dosomething1 and dosomething2 to avoid naming conflicts. If the alias is only needed within a single alias, why not make it local?

And parser speed setbacks? Are you using a 286? I'm not, I'm using a relatively slow PC, and thats a 1.4Ghz. They already have processors more than double mine. The "speed setbacks" you are talking about are 10nanoseconds. Yeah, 10 billionths of a second. Are you honestly going to tell me that 10ns is so important to you that people should be
deprived of this feature so your script runs in 10 seconds rather than 10.000000001 seconds?

Oh and again I ask, why exactly does local aliases create such complexity and speed issues yet your constants suggestion doesn't?

You are obviously not familiar with common programming philosophy and/or structure. I will not continue any discussion related to my suggestion of adding constants with you since it's obvious that you are quite uneducated on this matter. However, please stop bringing up out-of-context posts. Use the appropriate thread for it if you want to comment on it.



I will not argue with you about your personal taste for coding (which however I find to be quite perverted by looking at your examples), I can only appeal to common sense on this point.



Many small nanoseconds can make up quite a few seconds in the long run. mIRC's script parser is already slow as hell, adding severe structure altering crap such as aliases within aliases would ONLY serve to make the parser even slower.

I mean COME ON!! When did you EVER see a interpreted language with functions inside functions? Or a compiled language for that sake? There's a REASON you know!

!"#¤



By now this should be obvious. If you need to learn more about programming, I advice you to use www.google.com.

I've been programming for about 10 years now, I do NOT need you to come and tell me I don't know what I'm talking about. All your reply said is "I'm not answering that" or "That's a matter of opinion" give me a break! So because your opinion is it is complex and useless it shouldn't be added? Isn't that a matter of opinion? If you are dismissing my opinion that it is NOT complex and it is NOT useless I can just as easily dismiss yours.


Python supports local function definitions. Pascal/Object Pascal/Delphi supports nested functions (as does Innerfuse Pascal scripting, an interpreted language). Algol supports nested functions. The C++ library Boost supports local functions in the form of Lambda functions. The gcc compiler will let you use a local function in C. Fortran 90 includes "contained functions" which are essentially local functions. As of Perl 5, perl supports nested functions (perl is also an interpreted language). PHP supports nested functions (PHP is also an interpreted language). (Edit) I forgot, Ruby also supports nested functions (Ruby is also an interpreted language). Also in C++, you can declare a local class which in turn can have member functions which then act as local functions. Java also supports function local classes. Javascript also supports local functions (Javascript is also an interpreted language).

But you're right, I'M the one who needs to learn more about programming because I don't know what I'm talking about. So I guess you must be right, no languages support nested functions... except the dozen languages I just mentioned there. I'm sure there are many more languages that support nested functions, however I think I've proved my point.

I stand corrected, nested functions are existent within several languages, both compiled and interpreted ones (I would however like to point out that classes is a whole other story).

Still, the fact remains that adding such structural changes to the mIRC scripting language is very likely to decrease performance severely. However, if you really think that the parsing engine in mIRC is built in such a way that this would not make any notable* difference in execution speed, you are naive. And I might as well be paranoid. Let the benchmarks decide

The reason I'm so engaged in this issue is that I am currently working on a very large and cpu-demanding script that has caused me alot of headaches performance-wise. I would hate to see mIRC become even slower.

* By notable I mean seeing a distinct difference in performance when benchmarked

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.