For Lax

[Lax]

I'm a rude prick when it's deserved. As ml2517 says, why not let it be coded before whining about how you think it's going to be. As Plazmic says, you wont be using /varset ${mystring} because that would get pre-parsed.

It's nice of you to help with the item structure or whatever else you do. I agree with you that it would be counter-intuitive to do /varset ${mystring} *snicker*.

We dont do /varset @mystring right now do we? No, it's /varset mystring. So why would we change it to /varset ${mystring}? You're just making stuff up.

End the discussion already, you're not making yourself look any better and you're definitely not winning.. just accept it.

[iluvseq]

I accept it, and thats fine.

However, I also found /varset foo to be counter intuative.

You must forgive me, I've been programming Perl and PHP for years.

A variable starts with some character ($ in both of those languages) ALL THE TIME.

It's never "plaintext for assignment, special start character for usage"

ie: it's $foo = 1; print $foo. Not "foo = 1; print $foo"

I am constantly haveing to fix bugs in my macros (my bugs) cause I do /varset @foo

Plazmic: I understand completely that the underlying mechanism is a numeric comparison. In every language, as you say, it all boils down to numeric comparisons. However, thats behind the scenes.

For the coder using a language (not the developer creating the parser/executor for the language) the whole concept of "if a variable is defined, it's true" holds true for both strings and numeric variable types (with "" and 0 being special cases of "defined, yet false")

Since you support this notation for numeric types, it follows to reason that it would be supported for string types as well. I can accept that it won't be, however, I don't really understand WHY it wouldn't be, other than to think that it might add some complexity to the parser.

It is well within your rights to opt for a simpler parser, yet a more complex user experience if you wish. Hell, it might even make it faster, since your parser doesn't have to pay attention to things like the "quote state"

However, you've got to admit that having "two syntaxes" for variables is a tad odd. (ie: @MyVar is a variable when you want the value, MyVar is a variable when you are assigning to it)

I had (incorrectly) assumed that this counter-intuative kludge was going away with the conversion to ${} style variables.

Again, I'm not saying it's wrong. A simpler parser probably makes sense given that we want things to execute as balls out fast as we can.

Anyway, I hope that you can see that I wasn't trying to piss anyone off. I made an invalid assumption regarding /newif in my intial "bug" report that Lax locked. If you are objective I think you can see that my assumption is certainly reasonable and logical, especially given the "way it's done" in languages like Perl or PHP. When Lax was rude to me right off the bat for no reason, I tried to stay reasonable, but since he didn't give me much to go on other than a slammed door in my face.

I'm honestly trying to do two things here:

A) learn macroquest so I can write better scripts
B) improve macroquest

Thank you for taking my comments in that spirit, and please, try not to be so quick to assume that I am just another newb pulling things out of my ass. I really don't think my posts reflect that, but who knows, maybe I really am a moron.

[Lax]

Allowing you to use @ to read the data inside a variable through the parser is different from not using it in order to modify the variable.. Common mistake to /varset @x instead of /varset x. The parser is separated from the part that's setting the value, we're not changing that anytime soon.

We're not writing PHP or Perl, so we can have our parsing done beforehand and not worry about it Our commands have to start with / (well they dont "have to", but it would fuck people over if they didnt) and we're not implementing assignment operators, etc.

Anyway, glad this is over with.