Delayed evaluation of expressions [was Re: Time we switched to unicode?]

[Rustom Mody]

On Thursday, March 27, 2014 5:13:21 AM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 27 Mar 2014 09:24:49 +1100, Chris Angelico wrote:

> > wrote:
> >> Now actual python
> >> def sumjensen(i_get, i_set,lower,upper,exp):
> >>     tot = 0
> >>     i_set(lower)
> >>     while i_get() <= upper:
> >>         tot += exp_get()
> >>         i_set(i_get() + 1)
> >>     return tot
> >> i=0
> >> a=[3,4,5]
> >> i_get = lambda : i
> >> def i_set(val):
> >>    global i
> >>    i = val
> >> exp_get = lambda : a[i_get()]
> >> call as sumjensen(i_get, i_set, lower, upper, exp_get)
> >> [Note that because of lambda's restriction to being only an expression
> >> I have to make it a def because of need for  global]
> > You prove here that Python has first-class expressions in the same way
> > that 80x86 assembly language has garbage collection. Sure, you can
> > implement it using the primitives you have, but that's not support.

> +1

> Any language can work around the lack of a language feature by sufficient 
> layers of indirection, but that's not the same as having that language 
> feature.

> Beyond a certain minimum feature set, all languages are Turing complete, 
> and so in one sense are of equivalent power. But they're not all of equal 
> expressiveness. Python is awesome, it is very expressive, but there are 
> certain things you can't write directly in Python, and have to resort to 
> circumlocutions instead.

Of course.

And there are different grades of circumlocution -- of 'coding-up' --
a missing feature.


Terry said:
> One passes an unquoted expression in code by quoting it with either
> lambda, paired quote marks (Lisp used a single '),

Steven responded:
> Passing *strings* and *functions* is not the same as having compiler
> support for delayed evaluation. At best its a second-class work-around. 

I was merely pointing out that 'passing strings' and 'passing functions'
as 'coding-up' of some desirable but unavailable feature are very different
levels of work-around.

In fact there are actually 3 styles and levels of circumlocution

1. You dont have a certain language -- blub?? -- feature set.
So... code it up and write its interpreter as eval_blub.

2. You dont have a feature-set but can see similarity in some obtuse
host-language (in this case python).
So you code up a mini-translator for your feature-set neatly written to obtuse 
hostly written and then eval (note python eval not blub eval)

3. You dont go outside the language framework and into any eval-ish
mode at all.  Good ol subroutine libraries to classes for abstraction
to first-class functional abstraction -- all fall into this category