4 ms·
Hurts my eyes just a liiitle bit. Methinks The MUSIMP/MULISP-approach would be less painful. Firstly you find a way to transform the language in S-expressions a
by timonoko 6y ago
Hurts my eyes just a liiitle bit. Methinks The MUSIMP/MULISP-approach would be less painful. Firstly you find a way to transform the language in S-expressions and then you just write regular lisp-macros. This would be hidden from regular Python-user, of course. As I recall the macrodefinitions were already totally unreadable if transformed into Algol/Python, so no worry about syntax.
- teataster 6y agoWith the level of lisp-hate out there, this approach might make this feature less likely to happen. It's quite a sound idea tho.
- timonoko 6y agoYou do not actually need to see Lisp-code at all. In Musimp you could write a macro in Algol, but you had to understand properties of the S-code. Thus you would write 1+2 as LIST('+,1,2) which was then printed out as [+,1,2], +(1,2) or 1+2 depending on the situation and properties of the symbol '+.
- seg_lol 6y agoThere are so many good ideas that are trapped in the past, tens hundreds or thousands of years old.
- okmarker 6y agoThis is a sound and logical approach, so it won't happen in Python.
- seg_lol 6y agoWow! I had no idea that Microsoft made a Lisp?! MuLISP [0] I think there are two issues with the implementation of macros, and I am not really qualified, but this the internet so here goes. 1. Getting access to the quoted parse tree 2. Writing code to either generate, modify, etc, that parse tree. So folks already do (2) by spraying code into a buffer and exec or evaling it. They do some of (1) by reading the textual src, the bytecode or the parse tree. Mentioned elsewhere in the thread are MacroPy and HyLang. All of that said, I think a language with better semantics about deferred evaluation or a pre-eval step (maybe it doesn't need need full macro macros), who knows. One thing that I found really powerful in Zig [2] and Dlang are the facilities around CTFE (compile time function evaluation) [1] and how they obviate solve many of the same problems. Minor nit, I think the PEP could have done a better job showing now HOW it could be used, but what EXISTING programs could be made simpler or achieve things not possible with the current system. I do think that some sort of lightweight code generation step could both reduce the lines of code, make things simpler for the outer layers of the stack and make things more performant. Obviously, they can go the other way, but limiting the upside because of possible downsides isn't something we should do with code. Python already has an infinite number of ways to have unmaintainable, inscrutable code, you should see my list comprehensions and my itertools code! :) What is another one if it captures more of the original essence of Python? [0] http://www.edm2.com/index.php/MuLISP http://www.edm2.com/index.php/MuLISP > In addition to an interpreter and compiler the system includes an editor with a WordStar-like command set Wait what? I am getting flash-forwards of a ColorForth like environment for Lisp using DOS graphics. This is like some retro-futuristic timeline where Microsoft went down the Lisp+Xenix path! [1] https://en.wikipedia.org/wiki/Compile_time_function_execution https://en.wikipedia.org/wiki/Compile_time_function_executio... [2] Which also mentions Terra, which I think should be required in any discussion around macros https://news.ycombinator.com/item?id=13761571 https://news.ycombinator.com/item?id=13761571 https://en.wikipedia.org/wiki/Compile_time_function_execution https://en.wikipedia.org/wiki/Compile_time_function_executio...
- lispm 6y ago> I had no idea that Microsoft made a Lisp They didn't. It was 'made' by the company Soft Warehouse and sold through Microsoft.