mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#50926 23/09/03 03:14 PM
Joined: Apr 2003
Posts: 8
N
NetVoiD Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
N
Joined: Apr 2003
Posts: 8
I think this would be nice to allow aliases to be used inside an alias. For example, instead of this:

Code:
alias stats {
 echo -a Processor: $dll(a.dll,cpu,0)
 echo -a Memory: $dll(a.dll,mem,0)
 echo -a Screen: $dll(a.dll,scr,0)
}


We could have this:

Code:
alias stats {
 ; Instead of making an alias local for the current script
 ; which is already done with -l, the point here is to make
 ; it local to the alias
 alias -l i return $dll(a.dll,$1,0)
 echo -a Processor: $i(cpu)
 echo -a Memory: $i(mem)
 echo -a Screen: $i(scr)
}


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.


NetVoiD @ Undernet
IRC isn't real life..
#50927 23/09/03 03:28 PM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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. At least I won lunch.
Good philosophy, see good in bad, I like!
#50928 23/09/03 05:21 PM
Joined: Aug 2003
Posts: 72
V
Babel fish
Offline
Babel fish
V
Joined: Aug 2003
Posts: 72
Well, actually this could be a beggining of objet oriented programming, it would be pretty usefull

#50929 23/09/03 06:04 PM
Joined: Apr 2003
Posts: 26
P
Ameglian cow
Offline
Ameglian cow
P
Joined: Apr 2003
Posts: 26
Yeah, great idea laugh

#50930 23/09/03 07:46 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
I like the idea. I think it could be very useful.

#50931 23/09/03 09:56 PM
Joined: Dec 2002
Posts: 1,922
O
Hoopy frood
Offline
Hoopy frood
O
Joined: Dec 2002
Posts: 1,922
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?

#50932 23/09/03 11:02 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Umm... what in the hell are you talking about? It would work just like any other alias, except local to a function.

#50933 24/09/03 12:33 AM
Joined: Dec 2002
Posts: 1,922
O
Hoopy frood
Offline
Hoopy frood
O
Joined: Dec 2002
Posts: 1,922
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.

#50934 24/09/03 02:00 AM
Joined: May 2003
Posts: 161
A
Vogon poet
Offline
Vogon poet
A
Joined: May 2003
Posts: 161
Not all commands are evaluated immediately. Otherwise, /set would never be able to get the variable name.

#50935 24/09/03 11:43 AM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
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:
Code:
alias foo {
  ....
  alias -l i return $dll(blah.dll,Blah,$1)
  echo -a $i(one)
  echo -a $i(two)
}
alias bar {
  ....
  alias -l i return $dll(another.dll,Something,$1)
  echo -a $i(one)
  echo -a $i(two)
}
as opposed to the current way:
Code:
alias foo {
  ....
  echo -a $i1(one)
  echo -a $i1(two)
}
alias bar {
  ....
  echo -a $i2(one)
  echo -a $i2(two)
}
alias -l i1 return $dll(blah.dll,Blah,$1)
alias -l i2 return $dll(another.dll,Something,$1)

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.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
#50936 24/09/03 01:58 PM
Joined: Jun 2003
Posts: 242
R
Fjord artisan
Offline
Fjord artisan
R
Joined: Jun 2003
Posts: 242
That is a great idea smile

#50937 24/09/03 05:22 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
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.

Last edited by cold; 24/09/03 05:30 PM.

* cold edits his posts 24/7
#50938 25/09/03 12:31 AM
Joined: Dec 2002
Posts: 37
O
Ameglian cow
Offline
Ameglian cow
O
Joined: Dec 2002
Posts: 37
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.


Bloop
#50939 25/09/03 05:41 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
And your arguments are...? Sorry, I'd like to know.


* cold edits his posts 24/7
#50940 25/09/03 06:10 PM
Joined: Dec 2002
Posts: 37
O
Ameglian cow
Offline
Ameglian cow
O
Joined: Dec 2002
Posts: 37
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.


Bloop
#50941 26/09/03 12:14 AM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
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.


* cold edits his posts 24/7
#50942 26/09/03 06:07 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
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?

#50943 26/09/03 07:47 PM
Joined: Dec 2002
Posts: 37
O
Ameglian cow
Offline
Ameglian cow
O
Joined: Dec 2002
Posts: 37
Quote:

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?


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.

Quote:

How will it complicate code? I see it simplifying code.


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.

Quote:

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?


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!

!"#ยค

Quote:

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


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


Bloop
#50944 26/09/03 08:30 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
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.

Quote:
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!

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.

#50945 26/09/03 08:57 PM
Joined: Dec 2002
Posts: 37
O
Ameglian cow
Offline
Ameglian cow
O
Joined: Dec 2002
Posts: 37
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 wink

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


Bloop
Page 1 of 2 1 2

Link Copied to Clipboard