Static aliases (script macros) - mIRC Discussion Forums

Consider....

Code:

alias -s test { $1 $2 }
alias dothis {
  ; Using $test
  return $+(Test=, $test)
  ; The next line is what mIRC thinks the last line looked like
  ; return $+(Test=, $1 $2)
}
; $dothis(1, 2) - returns "1 2"

Note: the -s argument to "alias"...

Is that a good enough explaination, or should I describe better?

I think I see where you're going with this. You want to be able to do like C can do with a #define. Plop it in anywhere, and have it take the form it's defined as, then process. I suppose it could be handy, and (when doing long, tedious tasks) could prove useful.

Still think you could make an alias do all the work for you, where you wouldn't need a macro.

Quote:

I think I see where you're going with this. You want to be able to do like C can do with a #define. Plop it in anywhere, and have it take the form it's defined as, then process. I suppose it could be handy, and (when doing long, tedious tasks) could prove useful.

Yes exactly...

Quote:

Still think you could make an alias do all the work for you, where you wouldn't need a macro.

The same could be said for the C language though too (constants and functions could replace macros)...

I think I now understand your concept. However, the difference is that C (and variants) is a compiled language - mIRC scripting is an interpreted language.

The benefit of the C #define comes at the compilation stage, the short code is inserted instead of calls to functions - this makes compilation a little bit easier (and there are some benefits at run time, depending on the nature of the code).

However, in the interpreted language case (i.e. mIRC), the interpreter would have to find the code snippet, insert it into the script in memory, and the continue execution. In this case, it is quicker and easier just to find the alias or identifier (/xx or $xx), and then continue with execution.

The C #define statement has some nuances about passing of parameter any attempt to do the same for the interpreted mIRC scripting language would also introduce nuances (C #define interpretation of parameters is very literal). Would these be interpreted as "bugs" or "features"?

Bottom line, nice thought and discussion, but I don't think it is necessary or "improved".

Cheers,

DK

Quote:

The C #define statement has some nuances about passing of parameter any attempt to do the same for the interpreted mIRC scripting language would also introduce nuances (C #define interpretation of parameters is very literal). Would these be interpreted as "bugs" or "features"?

I'm not suggesting support for (or clone of) #define. The static alias can never be passed with arguments, problems solved?

Code:

alias -s test $1 $2
alias do {
  echo -s $test is valid
  echo -s $test($1) would generate an error
}

Nesting would be nice too... I would like to create no-argument identifers for signals...
[code]
alias -l sigidentifers {
alias -s sigtime $ctime
alias -s lastname $1
alias -s ok $true
}
; With support for static aliases
on *:signal:TEST:{
sigidentifiers
if ($sigtime > 0) echo -s TIME
if ($lastname == $me) echo -s ME
if (!$ok) halt
}
; Without support for static aliases
on *:signal:TEST:{
set -u0 %sigtime $asctime
set -u0 %lastname $1
set -u0 %ok $true
if (%sigtime > 0) echo -s TIME
if (%lastname == $me) echo -s ME
if (%ok) halt
}

not sure where you are going with this ...

Code:

  
alias -l sigidentifers 
{
  alias -s sigtime $ctime
  alias -s lastname $1
  alias -s ok $true
}; 

With support for static aliases
on *:signal:TEST:{
  sigidentifiers
  if ($sigtime &gt; 0) echo -s TIME
  if ($lastname == $me) echo -s ME
  if (!$ok) halt};
 
Without support for static aliases

on *:signal:TEST:{
  if ($asctime &gt; 0) echo -s TIME
  if ($1 == $me) echo -s ME
  if $true halt
}

or even: 

alias -l sigidentifers 
{
  if ($1 &gt; 0) echo -s TIME
  if ($2 == $me) echo -s ME
  if $3 halt
}; 


on *:signal:TEST:{
  sigidentifiers $asctime $1 $true 
}

Mind you, debugging using "static" would also be a nightmare:

What would "/do fred" return?
"Invalid command" in "/do" may not shed too much light!

Cheers,

DK

This could have some use, and it would probably be fairly simple to implement.

Workaround:

Code:

alias test return $($1 $2,0)
alias dothis {
  ; Using $test
  return $+(Test=, $($test,2))
  ; The next line is what mIRC thinks the last line looked like
  ; return $+(Test=, $1 $2)
}
; $dothis(1, 2) - returns "1 2"

-genius_at_work

I'm not entirely sure where you're trying to go with this. IMHO, it'd do nothing but complicate mIRC procedures.

Aside from something like genius_at_work's example, you could just do something like:

Code:

alias dothis2 {
  var %test = $1 $2
  return $+(Test=, %test)
}

Like I do with my socket scripts:

on *:sockopen:test:{
  var %s = sockwrite -n
  %s GET /something.html HTTP/1.0
  %s Host: www.test.com
  %s
}

Maybe I'm missing what you're trying to do that would require said "static" aliases.

(Btw, when I use an alias to do some repetive things, I generally just: alias -l _somename { })

I don't see how this complicates things, and it's completely a "if you don't like it - don't use it", feature. Of course it looks different, but that's hardly a reason to criticize.

I can see what you're trying to do but the method and the syntax you're suggesting is confusing and unnecessary.

Firstly, lacking a '/return' command doesn't really make much sense. It limits the macro to being a single statement and, from your examples, it seems like you want it to simply regurgitate existing identifiers using new names.

In fact the only one of your examples that couldn't be done right now using a regular alias with the /return command are the ones using $n parameters. Personally I'd rather see an identifier to access identifiers/variables from a scope outside the existing alias. This would enable you to do what you want and be a lot more dynamic since it would allow anything that used it to also accept parameters itself.

Your method does't seem very practical for signals anyway. The ability for scripters to write signals that provide identifiers in signal events is all well and good (I've suggested this before), but if the scripter writing the signal event has to call an alias to generate them doesn't that defeat the object somewhat? Surely it makes sense for the identifiers to be supplied when the /signal command is used.

Quote:

I can see what you're trying to do but the method and the syntax you're suggesting is confusing and unnecessary.

That's ok, I Understand, few people can keep up with me.

Well, not proposing anything new... UNIX shells and c programming languages both support such things, so why not?

I'm open to other ways of impleamenting... what do you suggest?

Quote:

... UNIX shells and ...

Can you please describe to me how Unix shells support this feature?

As previously mentioned, the C, C++ support for this feature is based on the compilation processes and, thus, is not suitable for interpreted languages.

Cheers,

DK

I think this would be a great addition. Though it's too confusing to call it "static aliases". It would be much simpler to just call it "macros". And be able to use parameters, only using a different sequence, obviously, such as $$$. For example:

Code:

macro debug { echo -s Event $event from nick $nick }
macro chantext { on *:TEXT:$$$1:#mychannel:msg #mychannel $$$2 }
  
  
chantext(*poop*, You can't say poop in here.)
chantext(*rawr*, Oh baby-- i love it when you rawr.)
chantext(!list, You'd better stop that!)

on *:JOIN:*:debug | haltdef\