Hi Tomas, > > In PicoLisp, as you know, 'prog' is a function. > > I think we just use different terminology.
Yes, that's the problem ;-) > I prefer distinguishing > different flavours of "functions". For me, the traditional definition > of "function" is a piece of code that works with already evaluated > arguments. "Macro" would then fit somewhere between "function" and full > FEXPR. I would not put a macro into a category similar to a function. I think these are completely different concepts. A macro is often not more than a simple textual replacement (e.g. a constant). Wikipedia says about "Macro (computer science)": A macro (from the Greek μάκρο for "big" or "far") in computer science is a rule or pattern that specifies how a certain input sequence (often a sequence of characters) should be mapped to an output sequence (also often a sequence of characters) according to a defined procedure. The mapping process that instantiates (transforms) a macro into a specific output sequence is known as macro expansion. This is also how I understood it. > But probably distinguishing between "function", "macro" and > "fexpr" doesn't make sense when everything happens at the same time, > i.e. run-time? Well, at least in PicoLisp, distinguishing between "function" and "fexpr" doesn't make much sense. On the lowest interpreter level, they are all fexpr's anyway. The differences are only whether arguments are evaluated at all (e.g. 'setq': It never evaluates its first argument), or - if they are evaluated - when and how often (think of 'while': The first argument is evaluated, but the following may be evaluated never, once, or many times). Even '+' is a macro in your sense, as it sometimes doesn't evaluate all its arguments (this happens when one of the arguments evaluates to NIL). So I would give up trying to find a terminology for differentiating "true" functions from fexpr's - and a possibly infinite number of intermediate stages. > > There is no processing taking place, at any time, which would > > transform the body of 'prog' into some other form. Instead, it is > > executed directly. > > That is only an implementation detail, that you decided to optimize > 'prog' and write it directly in native language (because of the need for > speed and the lack of a compiler). > > > There is a 'macro' (in the above sense) function in PicoLisp. > > > > (de macro "Prg" > > (run (fill "Prg")) ) > > > > It takes an executable body (list of expressions) in "Prog", processes > > it with 'fill' (which results in a modified list), and then uses that > > result for execution (running it). > > If you implemented 'macro' directly in C, you wouldn't think of it as > a macro anymore? No, of course I would be always aware that it is a macro! It is very different from a function, because it creates a new executable body each time before it is run. This has consequences: It produces garbage (i.e. it executes much slower), the resulting code is not pointer-equal to anything else, cannot be debugged etc. > > To my understanding, a "macro" is a piece of code which is processed > > (by a (pre)compiler or an equivalent software), resulting in a _new_ > > piece of code which is then used instead. > > Conceptually, 'prog' can be easily written as a syntactic transformation > passing the result to 'run'. > > (de prog P (run P 1)) > > Looks pretty much the same as the 'macro' definition above. Yes, but it is not the same. You can set a breakpoint before the 'run'. You can (vi 'prog) or (edit 'prog) to modify it. You can pass it to another function. Cheers, - Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
