Gregory Ewing :
> Marko Rauhamaa wrote:
>
>> def main():
>> try:
>> guard_it()
>> except ValueError:
>> # I'm having none of it!
>> resume "CarryOn!"
>>
>> The problem is, how can the file f unclose itself when work resumes?
>
> The same thin
Marko Rauhamaa wrote:
def main():
try:
guard_it()
except ValueError:
# I'm having none of it!
resume "CarryOn!"
The problem is, how can the file f unclose itself when work resumes?
The same thing could happen in Scheme, though. Re-enteri
Chris Angelico wrote:
Okay. Now let's suppose that, instead of "73" in the first step, you
have "ask the user for an integer". Are you allowed to eliminate this
prompt, since the result of it cannot possibly affect anything?
That's an excellent question. The answer is no, you're
not allowed to
On Thursday 20 October 2016 04:57, Chris Angelico wrote:
> Short-circuiting depends only on what's known *prior* to that
> evaluation. Dead code elimination removes the notion of time:
Surely not. I understand "dead code" to mean the same as *unreachable* code:
code which cannot be reached by an
Chris Angelico :
> On Thu, Oct 20, 2016 at 3:51 AM, Marko Rauhamaa wrote:
>>
>> def print(world, text, cont):
>> return cont(World(past=world, offset=text))
>>
>> def print_x_then_y(world, x, y, cont):
>> return print(world, x, lambda world2: print(world2, y, cont))
>>
> [
On Thu, Oct 20, 2016 at 3:51 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>> Okay. Now let's suppose that, instead of "73" in the first step, you
>> have "ask the user for an integer". Are you allowed to eliminate this
>> prompt, since the result of it cannot possibly affect anything? And if
>> no
Chris Angelico :
> Okay. Now let's suppose that, instead of "73" in the first step, you
> have "ask the user for an integer". Are you allowed to eliminate this
> prompt, since the result of it cannot possibly affect anything? And if
> not, why not?
I would guess yes; that's how Python works as wel
On Wed, Oct 19, 2016 at 9:26 AM, Gregory Ewing
wrote:
> The things being reasoned about -- the actions -- are
> not themselves functions, but that doesn't mean there's
> any cheating going on. Would you say it was cheating
> to perform algebraic manipulations on an expression
> involving numbers o
Chris Angelico wrote:
You can take your
original set-builder monad and turn it into genuinely functional code;
show me that you can do the same with I/O. Otherwise, what you're
really saying is "we can cheat until we can do I/O", not "we can do
I/O in a functional way".
I don't think I'm saying
On Tue, Oct 18, 2016 at 9:50 PM, Rustom Mody wrote:
> Now we can functionalize all this by making 'the world' as a parameter to our
> functions.
> Greg talks of this as do other writings on functional IO
> I personally find talking of 'world' as though its an object in my little
> world to be a s
On Tuesday, October 18, 2016 at 4:07:53 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico wrote:
> > If you want to prove to me that monads are still functional,
>
> Ultimately, monads are simply the pipelining pattern. It is used
> extensively in Unix shells. (I don't know Microsoft's PowerShel
Chris Angelico :
> I think, it is patently false to claim that Haskell is purely
> functional - but the I/O monads are a crucial feature in making the
> language useful.
As soon as you accept that values can exist in "a superposition," that
is, in a not-yet-fully-materialized form, you can see tha
Chris Angelico :
> If you want to prove to me that monads are still functional,
Ultimately, monads are simply the pipelining pattern. It is used
extensively in Unix shells. (I don't know Microsoft's PowerShell, but it
used to be called "Monad".)
> Otherwise, what you're really saying is "we can c
On Tue, Oct 18, 2016 at 8:56 PM, Rustom Mody wrote:
> One thing probably is correct in what you are saying (if you are saying!):
> The IO monad cannot be programmed at the vanilla user/programmer level but
> must
> be hardwired into the system (for an FPL of course; for python its all demo
> any
On Tuesday, October 18, 2016 at 2:55:07 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Oct 14, 2016 at 9:52 AM, Gregory Ewing wrote:
> > A bit more on SMFs, and then some I/O.
> >
> > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads2.html
>
> Finally finished reading this
On Fri, Oct 14, 2016 at 9:52 AM, Gregory Ewing
wrote:
> A bit more on SMFs, and then some I/O.
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads2.html
Finally finished reading this - it's been up in a tab in Chrome for
the past few days.
So here's how I summarize y
Gregory Ewing writes:
> A bit more on SMFs, and then some I/O.
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads2.html
Thanks.
It would be good to spell out SMF at the start of the page.
"The definition of / above" (__truediv__ method) was not given "above"
(in th
A bit more on SMFs, and then some I/O.
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads2.html
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
18 matches
Mail list logo
