Forums Bug Reports $!ident bug?

Yes yet another parser related quirk ( i fully realise this, before i get "flamed" ).

After some heated debate on IRC im still not sure wheter to class this as a bug.

$!ident($me) evaluates => $ident($me)
$!ident( $me ) evaluates => $ident( Mpdreamz )

where

$!ident( [ $me ] ) evaluates => $ident( Mpdreamz )
makes more sense to me

Khaled you've never given any statements anywhere on what exactly the intended behaviour is when parameters are used:



but wheter or not the parameters are suppose to evaluate or not both cases above should behave the same in my opinion.

Since you've added this to quickly stop evaluation on timers and scon commands



i feel that not evaluating the params should be default wheter or not they are surrounded in spaces.


Im fully aware however that this might not be a changeable behaviour as it is now but for the sake of our IRC discussion i would really love to hear from you how $!ident($param) and $!ident( $param ) should act.

Thanks!

this might sound n00b but i always thought " $! " was to refer to the stuff u type on an $input

also looks like $! ident has a space in between..how does mirc know if the " $! " is not part of a $input? shouldnt it be $!ident instead?

$! on its own reffers to $input value.

$!identifier prevent $identifier to be evaluated
$eval($!me,2) => $me
$eval($!!me,2) => $!me
$eval($!!!me,2) => $!!me

etcetera.

In my opinion this is not a bug, not even a quirk, just the way the parser works. What is probably going on (or at least what appears to be going on) is that when the parser sees a "$", it checks whether the next character is a "!". If it is, it considers "$" and every non-space character following "!" plain text and happily goes on to deal with the next space-separated token as if nothing special happened.

With this in mind, the current behaviour is entirely expected: mirc doesn't even know that "$!ident( $param )" is supposed to be an identifier (that should not be evaluated); it never got as far as parsing it as such. "$!ident( $param )" is evaluated in the same way as "foo $param bar", except instead of the plain text "foo", we have the plain text "$ident(", same for "bar" and ")".

Changing this behaviour now would probably make things easier for some scripters using timers, as they would just stick a ! and not worry about the parameters, spacing etc. However such a change in the parser is probably nontrivial but more importantly, it would break a lot of scripts.

hmm i'm not sure about the easier for scripters bit ;P it seems like $eval($ident( ),0) would be pretty much equivalent to how Mpdreamz suggests $!ident( ) to behave, at least in a large number of practical circumstances. if the contents of $!ident( ) includes a static comma, well that's ok because the parentheses surrounding it makes it plaintext. if it contains static unbalanced parentheses, well that would still cause confusion and possible problems with the proposed change

another point about the change is it would be quite difficult to return something as simple as "$ident(<value of $ident>)" i.e. what $!ident( $+ $ident $+ ) currently returns. it wouldn't be pretty

so yeah im afraid i can't support this. i can't support it like a loving parent might support their child in a time of crisis. i can't support it like Atlas supported the world in Greek mythology. i can't support it like Mpdreamz himself has supported me time and time again. i'm so sorry...

Qwerty i realize why it's doing what it does and i also fully realize this behavior cant be changed without possibly breaking scripts like i stated in the first post



I was merely stating that nowhere has the issue of evaluation or not evaluating the parameters been given a mention. But from how i read what was communicated back to us about $!ident i gather that it should NOT evaluate it's parameters, totally subjective of course.

That said i'm perfectly fine with parameters evaluating by default too (spaces or no spaces). As long as they behave the same, Since spacing parameters has no impact anywhere else I personally do feel its a quirk/design flaw all be it a really easy to explain one

I merely want to know wheter it was intended to not eval parameters and spacing was overlooked or wheter it was left in intentionally.

This is not a RFC, so no hard feelings jaytea!.

While Khaled may not have explicitly stated the rules which the parser uses, you clearly understand it. And if you understand it then you should be able to admit that it is a completely consistent behaviour, meaning it *cannot* be a bug. Whether or not you think it's intuitive or not is another issue altogether, and warrants a feature suggestion, not a bug report.

On a sidenote, if you're admittedly "not sure" whether or not something is a bug, then don't post a bug report- come back when you're sure. This is not Q&A- there's a General Discussion forums for that. Having the discussion here on it's actual validity only adds more noise for Khaled to sift through when trying to fix real problems.

I actually had you in mind when i posted this so i added that.

I guess the big culprit in posting this here is my interpretation of the logs (which is indeed open too interpretation so i wont use the word misinterpretation) in versions.txt about $!ident.

I just wanted to hear Khaleds intention on this and in all fairness this is the main thread Khaled posts on and whatever khaleds intention were about parameters will make this a "bug" or not something i cannot guess.

i.e I know it makes it plain text but he doesn't name it as such anywhere. He talks about stopping evaluation of an identifier and doesn't mention its effect on parameters anywhere.
The General Discussion thread is hardly used for topics like this.

I'm not whining for a change nor do i long for it because i realise its not gonna happen so posting in Feature Suggestions is just as pointless.

Looking back though i should have never posted this because i can almost guess what the intention was.