I don't understand why you'd mention that string concatenation is "right associative". Concatenation is associative, so I don't see how it matters in what order Lua evaluates it. Am I missing something?
E.g. a^(b^c) == (a^b)^c is not generally true, but a..(b..c) == (a..b)..c is. I mean suppose if you'd use the concat metamethod for something that doesn't behave like concatenation it would matter, but I don't see why anyone would want to do that.
You seem to have answered your own question, except you ended it with, but I don't see why anyone would want to do that.
It doesn't matter what you think is an appropriate use of the feature. Lua is a programming language. And there is nothing programmers love more than to abuse a feature in the language for something that is not intended.
Saying that it is right associative is simply providing information to the reader. What you do with that info is up to you.
Some info on why .. associativity is right2left here http://lua-users.org/wiki/AssociativityOfConcatenation
It does not quite explain what that "speed optimization" was though. I understand he/they came with concat chaining but that could have worked with left-to-right associativity too...
Related
Does anyone know how I can deobfuscate a lua script that uses xfuscator to hide it? The obfuscation looks like this. If anyone could give me a point into the right direction on how I can get this done that would bne awesome! I didnt share the source because I wanted help figuring out how to deobfusate myself and didnt want the answer!
https://gyazo.com/d2a9a2bcc602d1a1146491158271e3e6
See that long table? That's the real code. It's a pattern you see quite often with obfuscators. Other than that, keep in mind that _, __0 and such are all valid Lua identifiers, to you can have variables named like that.
_ is a function that turns a number into a character; __0 is a table that contains some standard functions. There's nothing special going on beyond that. If you see a __0[1]("Hello"), that'd be the same as print("Hello"); it just looks weird, because they put print into the __0 table at index 1.
Ultimately, the obfuscator just makes use of Lua features that people often don't understand well enough to understand what's going on. If you know the language though, it's all just smoke and mirrors.
Does anyone know how I can deobfuscate a lua script that uses xfuscator to hide it? The obfuscation looks like this. If anyone could give me a point into the right direction on how I can get this done that would bne awesome! I didnt share the source because I wanted help figuring out how to deobfusate myself and didnt want the answer!
https://gyazo.com/d2a9a2bcc602d1a1146491158271e3e6
See that long table? That's the real code. It's a pattern you see quite often with obfuscators. Other than that, keep in mind that _, __0 and such are all valid Lua identifiers, to you can have variables named like that.
_ is a function that turns a number into a character; __0 is a table that contains some standard functions. There's nothing special going on beyond that. If you see a __0[1]("Hello"), that'd be the same as print("Hello"); it just looks weird, because they put print into the __0 table at index 1.
Ultimately, the obfuscator just makes use of Lua features that people often don't understand well enough to understand what's going on. If you know the language though, it's all just smoke and mirrors.
I.e, if I have a record
-record(one, {frag, left}).
Is record_info(fields, one) going to always return [frag,
left]?
Is tl(tuple_to_list(#one{frag = "Frag", left = "Left"}))
always gonna be ["Frag", "Left"]?
Is this an implementation detail?
Thanks a lot!
The short answer is: yes, as of this writing it will work. The better answer is: it may not work that way in the future, and the nature of the question concerns me.
It's safe to use record_info/2, although relying on the order may be risky and frankly I can't think of a situation where doing so makes sense which implies that you are solving a problem the wrong way. Can you share more details about what exactly you are trying to accomplish so we can help you choose a better method? It could be that simple pattern matching is all you need.
As for the example with tuple_to_list/1, I'll quote from "Erlang Programming" by Cesarini and Thompson:
"... whatever you do, never, ever use the tuple representations of records in your programs. If you do, the authors of this book will disown you and deny any involvement in helping you learn Erlang."
There are several good reasons why, including:
Your code will become brittle - if you later change the number of fields or their order, your code will break.
There is no guarantee that the internal representation of records will continue to work this way in future versions of erlang.
Yes, order is always the same because records represented by tuples for which order is an essential property. Look also on my other answer about records with examples: Syntax Error while accessing a field in a record
Yes, in both cases Erlang will retain the 'original' order. And yes it's implementation as it's not specifically addressed in the function spec or documentation, though it's a pretty safe bet it will stay like that.
I'm quite puzzled how the syntax highlighting feature here on SO works, but I have seen similar somewhere else. How does this work?
Is there one parser which can parse multiple languages at once?
Or, are several passes of different parsers needed and the best parsing result is used?
Or, is only a shallow analysis performed and the language is then guessed based on heuristics?
And if one of these is true, how does it work?
Check out Javascript code prettifier on Google Code.
I would like to develop a converter that will accept math written in "freeform" or something like Wolfram Alpha would accept. For example: 2*x+(7+y)/(z^2) will be transformed to 2\cdot x+\frac{7+y}{z^{2}} (please ignore any syntax mistakes I might have made here) and vice versa. I was wondering if there exists a LaTeX library for C++/Java that parses and/or holds LaTeX expression in memory. If so, please share.
If not, how would you go about writing something like this? Is it okay to use normal Java/C++ code for this or should I use something like lex?
Yes, it is absolutely OK to write the parser for ‘freeform’ in Flex/Bison, in fact I’d recommend against using TeX, as that language was not written for parsing. I even remember having done exactly that (‘freeform’ to LaTeX) as an exercise with Flex and Bison and Kimwitu++, which allowed to perform arbitrary transformations before output. Note that you dropped the parentheses of your original formula. This might of might not be what you want in the general case.
For the other way round, the comments already mentioned that it’s nearly impossible to do in the general case. For restricted cases, Bison is good enough.