Invoking return through a function?

[Rustom Mody]

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