From a9b2799e6c53c00d628239366fb66ee77c3e3c84 Mon Sep 17 00:00:00 2001 From: Jon Michael Aanes Date: Sat, 15 Jul 2017 23:11:54 +0200 Subject: [PATCH] Changed a bit in the thoughts section in `function.lua`. --- function.lua | 38 +++++++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 15 deletions(-) diff --git a/function.lua b/function.lua index 268ca63..fd51040 100644 --- a/function.lua +++ b/function.lua @@ -1,31 +1,38 @@ --[=[ The function formatting module for pretty. How is one supposed to pretty print functions? Well, there are many different -formats, and no "best" one, only "best for the purpose". Lets first look at how -you could display the most raw data about a function. +formats, and no "best" one, only "best for the purpose". Lets start at the +simplest, and move towards abstraction. 1. The default Lua format: "function: 0x41f71c60" This is the default, and by far the easiest. Also, very uninformative. We only get a unique id for the function. 2. Include the arguments: "function (t, str) ... end" This is slightly more advanced, as it requires using the debug library to - discover the names of the arguments. In addition it adds a pseudo-correct - formatting for the function. Now we know the arguments, and if they possess - descriptive names, we can learn a lot about the function. + discover the names of the arguments. In addition it comes closer to a Lua + parsable formatting. We can know the argument names, and if these are + descriptive, we can learn some things about the function. 3. Include some documentation: "function (x) --[[math.cosh: Returns the hyperbolic cosine of x.]] ... end" - We retain the arguments and pseudo-correct formatting from above, and add - documentation taken from elsewhere (for example the Lua Reference Manual, or - LuaJIT webpage), as comments. This is great for explorative programming, as - we can read about the language from within the language. + We retain the arguments and almost parsable formatting from above, and add + documentation taken from elsewhere - Lua Reference Manual, LuaJIT webpage - + as comments. This is great for explorative programming, as we can read about + the language by just fiddling around with it. 4. Short names: "math.min" - Rather than giving an overly descriptive overview of some inbuilt, we assume - that we can find it by its standard name. With this one we gain complete - native representation, assuming the standard enviroment, of course. It won't - work at all with custom functions. + We can assume that an experienced Lua user might already know how any given + library function works, and would thus prefer a shorthand, rather than the + documentation. To that aim, we can use the short name/access path instead. + This is also ideal in places where we don't have a lot of space. + This representation is completely parsable, but won't necessarily work for + custom enviroment and user-defined functions. 5. Include source code: "function (a, b) return (a + b)/2 end" Now we find the source code somehow, and use it as the representation. This - is powerful because we can directly inspect the code. It won't work with - builtins, closured functions, or when fucking around with the source files. + is powerful because we can directly inspect the code. But it makes the + function representation a lot more bussy. It won't work with builtins, + closured functions, or when fucking around with the source files. It also + hits limits when functions are nested, as the debug library does not give + enough precision. + This also works nicely with 3. due to being able to read function + documentation from the source file. 6. Include closures: "(function () local i = 5; return function () i = i + 1; return i end end)()" In cases where a function has a closure, we can use debug.getinfo to get the names and values of the upvalues. We can then represent the closure, by @@ -42,6 +49,7 @@ you could display the most raw data about a function. `func_c` should produce the list: 2, 3, 4, 5, 6, 7, ... To break through this barrier, we need to parse the Lua AST, and that is beyond this project. + Closures also create extremely bussy output. --]=] -- Import