Re: Lambda in parameters

2020-12-19 Thread Abdur-Rahmaan Janhangeer
Greetings list,


Jane Street is well known for its love of functional programming in general
and of OCaml in particular.  If you don't know OCaml yet, I highly
recommend it.  You can think of it as Python with (static) types.

Yes i know OCaml when i was exploring haskell and the like.
At that time i was looking for companies who use OCaml etc
Did not come across Jane Street (If you know someone from there
tell them the question writer has a really twisted mind ^^)/.
I don't understand why though you would prefer OCaml over Python, Go, Java
etc for a company ^^

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Lambda in parameters

2020-12-19 Thread Abdur-Rahmaan Janhangeer
Greetings list,


 Why car and cdr?

Well obviously car is content of the address register and cdr is content of
data register.
Apparently an artefact of a early implementation of lisp.

Oh did not know that detail. More twists for sure. Thought lisp did not go
lowlevel.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Lambda in parameters

2020-12-19 Thread Abdur-Rahmaan Janhangeer
Greetings,

Very clear explanations, rewriting lambdas as a function
was the key to understand it. Did not know was a lisp inspiration.

My mind still spiralling XD

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Lambda in parameters

2020-12-19 Thread Greg Ewing

On 18/12/20 7:02 pm, Cameron Simpson wrote:

Frankly, I think this is a terrible way to solve this problem, whatever
the problem was supposed to be - that is not clear.


It demonstrates that a programming language doesn't strictly
need data structes -- you can do everything with nothing
but functions.

This is mainly of theoretical interest; it's not usually a
practical way to go about things. But it's a good exercise
in thinking about functions as objects to be manipulated.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list


Re: Lambda in parameters

2020-12-19 Thread Cameron Simpson
On 19Dec2020 07:39, Philippe Meunier  wrote:
>See also the example reduction
>here: https://en.wikipedia.org/wiki/Church_encoding#Church_pairs

Thank you for this reference. I've stuck it on my reading list.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list


Delegating to part of a subgenerator

2020-12-19 Thread Paolo Lammens
Dear all,

I've been struggling with the following problem, and I thought maybe there
is someone here in python-list who could shine some light on this.

Suppose we have a generator function `subgen`, and we want to wrap this in
another generator function, `gen`. For clarity, these are "full"
generators, i.e. they make use of .send, .throw, .close, etc. The purpose
of `gen` is to intercept the first value yielded by `subgen`, transforming
it in some form, and forwarding it on to the caller; after that, it should
just delegate to the rest of the generator iterator with `yield from`.

The problem is, the semantics of `yield from` expect a "fresh" generator
iterator, not a partially consumed generator. Indeed, the first value that
`yield from` will send to the iterator will be `None`, to start the
execution of the generator. But in this case we have already started the
generator, and to continue its execution we should really send whatever we
received after yielding the first value. However there's no way to specify
this with the `yield from` syntax.

A solution would be to re-implement the semantics of `yield from`, but with
an optional starting value (other than None) that will be sent to the
iterator as the initial value. However this means, as I said,
re-implementing the whole of `yield from`, i.e. handling .send(), .throw(),
.close(), etc., which is not ideal. So that would not be a good solution.
Am I asking for the impossible?

More details and an example in my original stackoverflow question:
https://stackoverflow.com/q/65369447/6117426

Best,
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Lambda in parameters

2020-12-19 Thread Philippe Meunier
Abdur-Rahmaan Janhangeer wrote:
>The aim of car is to return 1
>but i don't understand how lambda achieves this

Cameron Simpson's explanation is very good.  See also the example reduction
here: https://en.wikipedia.org/wiki/Church_encoding#Church_pairs

>This problem was asked by Jane Street.

Jane Street is well known for its love of functional programming in general
and of OCaml in particular.  If you don't know OCaml yet, I highly
recommend it.  You can think of it as Python with (static) types.

Best,

Philippe


-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Function returns old value

2020-12-19 Thread Michael F. Stemper

On 18/12/2020 00.09, Cameron Simpson wrote:

On 17Dec2020 14:22, Michael F. Stemper  wrote:

On 17/12/2020 03.57, Peter J. Holzer wrote:

On 2020-12-17 03:06:32 -, Bischoop wrote:



With newer vims that's rarely necessary though since they can
distinguish
between input that was pasted and input that was typed.


Mine doesn't seem to (vim inside a MacOS iTerm).


I thought that I was going nuts when I encountered that. Any idea how to
defeat such a so-called 'feature"?


You mean having vim figure that out? I dunno. I came here from vi and
haven't fully embraced al the stuff vim has.


What I want is for vi to treat all input the same, whether it comes
directly from the keyboard, or from a copy/paste buffer.

It did everything fine from '92 when I started using it on AIX until a
year or two back when I briefly went to Ubuntu 18.04 LTS. Then, I could
paste a command into it, and it would insert it into the text, rather
than executing it. Or, I'd paste (in input mode; repeatedly verified)
some TeX and it would decide that it was really a command and execute
it.

And I've just realized which group this is, so my complaint is
completely off-topic. Sorry.

--
Michael F. Stemper
Deuteronomy 24:17
--
https://mail.python.org/mailman/listinfo/python-list