On Tuesday, October 31, 2017 at 7:45:18 AM UTC+5:30, Alberto Riva wrote: > On 10/30/2017 12:23 AM, Rustom Mody wrote: > > On Sunday, October 29, 2017 at 9:52:01 PM UTC+5:30, Rick Johnson wrote: > >> On Sunday, October 29, 2017 at 9:19:03 AM UTC-5, Alberto Riva wrote: > > > >>> In a language like Lisp > >> > >> Python is nothing like Lisp, and for good reason! Sure, we > >> have a few lispers and functional fanboys who hang around > >> here, and sometimes Rustom can get a little preachy about > >> FP, but mostly, we tolerate the fanboyism -- so long as it's > >> not rabid fanboyism. > > > > Rick's personal comments are one of the standard entertainments of this > > list. Enjoy! > > > > The comments on FP are more problematic: > > > > - These misconceptions are more widespread than just Rick > > - They are right enough to be hard to refute > > - And wrong enough to cause confusion and misdirection > > - And irrelevant to (threads like) this one > > > > My super-short rejoiner to the FP-irrelevancy is: > > «If there is one key takeaway from functional programming maybe it should > > be: "Truth is a function of time" » > > > > In more detail: > > - Lisp (1960) was the second functional language; its predecessor was > > something called Formula Translator — usually shortened to Fortran (c. 1957) > > - By the late 80s, many FPers had begun regard Lisp as a setback for > > functional programming. [Dont get me wrong: Ive enjoyed Scheme more than > > any other > > programming language. Its just that conflating Lisp and FP is an error (in > > 2017)] > > > > More historical details at > > http://blog.languager.org/2015/04/cs-history-1.html and sequel > > > > At a more conceptual level, people dont get that there are two dimensions > > - the apply-lambda axis — usually called functional programming > > - the eval-quote axis — which has precious little to do with FP (and is > > more relevant to your question) > > > > These two dimensions of power uniquely coincide in Lisp (Scheme). > > > > As you correctly (almost) point out > > - Python is very much a lisp… its semantic under-belly > > - However, syntactically its more like C/Java etc in the sense of having a > > rigid > > fixed-at-language-design-time syntax > > > > More at http://blog.languager.org/2013/08/applying-si-on-sicp.html > > > > For a question like macros (syntax-extensions) that sits between the two > > your > > question is interesting and I am not sure I know how to do it… > > I remember seeing something about this recently but my google-foo is > > failing me > > at the moment > > > > However I would look at > > - PEP 263 https://www.python.org/dev/peps/pep-0263/ — Source Code Encodings… > > - Hooking into the codec module > > https://docs.python.org/3/library/codecs.html > > - hooking into ast module https://docs.python.org/3/library/ast.html > > > > An old attempt in this direction: > > http://code.activestate.com/recipes/546539/ > > > > You've already got the moral-hi-horse guys giving you the dope of why this > > is evil. Swallow if you like. My own lightweight > > suggestion would be that the natural pythonic way of unstructured exit is > > exceptions. Not as succinct as a tailormade syntax extension. But good > > enough IMHO > > > > PS I personally would be interested if you get this (syntax extension) > > running > > Thanks for the interesting reply! But once again: I was not proposing to > add lisp-style macros to Python; I have no interest in doing that since > I believe it's pretty much impossible :)
https://github.com/pythonql/pythonql is the example that shows how lisp-style extended-syntax (macros) can be done via file-encodings in a modern python. Or if you prefer modern lingo: “How to embed an internal DSL into python” Note: I am not recommending you take this line; just that its not impossible as you seem to imagine. My own feeling about lisp-macros is conflicted: - They are likely the most unique feature of lisp, putting it at the top of the blub-language tower - They are the single reason Lisp can never succeed like mainstream languages: Any significant Lisp sub-ecosystem will inevitably develop a macro set which succinctly and precisely expresses its needs but is arcane and incomprehensible to someone from another sub-ecosystem. This is Turing-completeness Lisp-specific style: The basic Turing-result is that programs can be arbitrarily complex to the point of being unanalysable. For mainstream languages that complexity sits squarely in the application For lisp there is a choice of simplifying the application by concentrating the complexity in a macro/DSL layer between implementation and application -- https://mail.python.org/mailman/listinfo/python-list