On Friday, October 14, 2016 at 10:31:36 AM UTC+5:30, Marko Rauhamaa wrote:
> Gregory Ewing :
>
> > Marko Rauhamaa wrote:
> >> This suggests even the promoters of functional programming
> >> intuitively prefer imperative programming, but that's ok as long as
> >> it's all functional under the hood.
Gregory Ewing :
> Marko Rauhamaa wrote:
>> This suggests even the promoters of functional programming
>> intuitively prefer imperative programming, but that's ok as long as
>> it's all functional under the hood.
>
> You make it sound like functional programmers like functional
> programming becaus
Marko Rauhamaa wrote:
This suggests even the promoters of functional programming intuitively
prefer imperative programming, but that's ok as long as it's all
functional under the hood.
You make it sound like functional programmers like functional
programming because it gives them a warm fuzzy f
Gregory Ewing :
> Steve D'Aprano wrote:
>> The way you can usually tell your functional language has given up
>> purity in favour of mutating implementations is that your code
>> actually runs with non-toy amounts of data :-)
>
> Hmmm. Your argument here seems to be: "Everyone knows that functional
Steve D'Aprano wrote:
The way you can usually tell your functional language has given up purity in
favour of mutating implementations is that your code actually runs with
non-toy amounts of data :-)
Hmmm. Your argument here seems to be: "Everyone knows
that functional languages are impractical,
On Wed, 12 Oct 2016 11:52 pm, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> "the implementation is free to use in-place mutations of the state object
>> – ... without letting anyone know that the implementation has given up
>> any functional purity."
>
> If it's impossible to tell that functio
Steven D'Aprano wrote:
"the implementation is free to use in-place mutations of the state object –
... without letting anyone know that the implementation has given up
any functional purity."
If it's impossible to tell that functional purity has
been given up, then in what sense has it been gi
On Sunday 09 October 2016 18:48, Gregory Ewing wrote:
> Here's the first part of the essay I said I'd write about
> monads:
>
>
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
Quoting from the essay:
"the implementation is free to use in-place mutations of th
Paul Rubin wrote:
Also if this operation is what it looks like, it's usually called
"bind". seq is something else entirely.
Ah, I hadn't realised there was already a function in
Haskell called seq -- sorry about that!
I don't really want to call the Python version 'bind',
because it seems a b
Anuradha Laxminarayan wrote:
seq f g h = f (\s1 -> g h s1)
better be written as
seq f g x = f (\s1 -> g x s1)
because naming conventions imply that h is function.
Well, for the subset of monads I'm talking about, it
always is a function -- it's the continuation to be
run after f and g.
--
G
On Tuesday, October 11, 2016 at 9:53:25 PM UTC+5:30, Anuradha Laxminarayan
wrote:
> On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing wrote:
> > Here's the first part of the essay I said I'd write about
> > monads:
> >
> > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/Demyst
Anuradha Laxminarayan writes:
> seq f g x = f (\s1 -> g x s1)
> because naming conventions imply that h is function.
Also if this operation is what it looks like, it's usually called
"bind". seq is something else entirely.
--
https://mail.python.org/mailman/listinfo/python-list
On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing wrote:
> Here's the first part of the essay I said I'd write about
> monads:
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
>
> Hope it's useful,
> Greg
Thanks, that made a very interesting read.
Paul Rubin writes:
>https://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf
Whoops, url changed:
http://emorehouse.web.wesleyan.edu/silliness/burrito_monads.pdf
--
https://mail.python.org/mailman/listinfo/python-list
Gregory Ewing writes:
> Oh, undoubtedly. I just don't think it helps understand how burritos
> are used in prog... er, that is, how monads... well, you know what I
> mean.
How about in math?
https://www.cs.cmu.edu/~edmo/silliness/burrito_monads.pdf
;-)
--
https://mail.python.org/mailman/lis
Paul Rubin wrote:
Well, at least I refrained from saying that monads are like burritos!
But they are! See: http://blog.plover.com/prog/burritos.html
Oh, undoubtedly. I just don't think it helps understand
how burritos are used in prog... er, that is, how
monads... well, you know what I mean.
On Sunday, October 9, 2016 at 1:18:32 PM UTC+5:30, Gregory Ewing wrote:
> Here's the first part of the essay I said I'd write about
> monads:
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
>
> Hope it's useful,
> Greg
Thanks Greg... looks v useful... the co
> Well, at least I refrained from saying that monads are like burritos!
But they are! See: http://blog.plover.com/prog/burritos.html
--
https://mail.python.org/mailman/listinfo/python-list
Gregory Ewing writes:
> Here's the first part of the essay I said I'd write about
> monads:
Thank you for tackling this.
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
You appreciate an important feature of this:
Often it is presented in a very abstrac
Gregory Ewing writes:
> Not sure where I got [h|t] from -- maybe I was thinking of Prolog?)
I've never used Prolog. Erlang is said to have Prolog-like syntax and
it uses [h|t], so maybe Prolog uses it too. (Erlang was originally
written in Prolog).
--
https://mail.python.org/mailman/listinfo/p
On 09/10/2016 11:35, Gregory Ewing wrote:
Paul Rubin wrote:
Gregory Ewing writes:
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
Well, at least I refrained f
Paul Rubin wrote:
Gregory Ewing writes:
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
Well, at least I refrained from saying that monads are
like burritos!
I
Paul Rubin wrote:
[h|t] should say h:t .
Thanks, corrected. (You can probably tell I'm not a regular
Haskell user. Not sure where I got [h|t] from -- maybe I
was thinking of Prolog?)
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Gregory Ewing writes:
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
Erratum in Haskell section:
Lists in Haskell are linked lists, and [h|t] represents a list
whose first element is h and the rest of the list is t.
[h|t] should say h:t .
--
https:/
Gregory Ewing writes:
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
--
https://mail.python.org/mailman/listinfo/python-list
Here's the first part of the essay I said I'd write about
monads:
http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
Hope it's useful,
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On 06/10/2016 00:27, Chris Angelico wrote:
On Thu, Oct 6, 2016 at 9:45 AM, BartC wrote:
Small languages are perfectly viable: the JIT version of Lua, for example,
is only about 225KB, and is very fast.
If I wanted to send you program.lua, and you didn't have Lua, I only need to
add luajit.ex
On Thursday, 6 October 2016 14:17:06 UTC+5:30, Gregory Ewing wrote:
> Paul Rubin wrote:
> > It's useful to write some Python things in monadic style, but monads
> > make the most sense as type operators, which don't map onto Python that
> > well.
>
> There probably isn't much point in using the
Ben Bacarisse wrote:
import Control.Concurrent
spam io = do x <- io;
print x;
print (x+1)
main = spam (do threadDelay (2*10^6); return 1)
It matches the Python in that the delay happens once. To get the
behaviour being hinted at (two delays) you need to re-bind the I
Paul Rubin wrote:
It's useful to write some Python things in monadic style, but monads
make the most sense as type operators, which don't map onto Python that
well.
There probably isn't much point in using the monadic style
in Python, since the main reason for it is to express
stateful proces
Rustom Mody wrote:
It is fair to say that Haskell's variadic function support is poorer than C's
[Collecting into a list fails for different types
If you want an arbitrary number of args of unrelated
types, you would need to define a wrapper type that
can encapsulate all the ones you're interes
Chris Angelico wrote:
There's one other consideration. With Python functions, you often want
to run a function for its side effects and ignore its return value.
You can't just ignore a return value in Haskell. The
return value is always going *somewhere*. If you leave
off an argument, the resul
On Thursday, October 6, 2016 at 11:31:13 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Oct 6, 2016 at 3:57 PM, Gregory Ewing wrote:
> > Chris Angelico wrote:
> >>
> >> Hence my
> >> query about how variadic functions and automatic currying work - how
> >> does it know whether to curry or run?
> >
>
On Thu, Oct 6, 2016 at 3:57 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> Hence my
>> query about how variadic functions and automatic currying work - how
>> does it know whether to curry or run?
>
>
> Calling it "automatic" was probably a bad choice of words.
> I don't mean to imply that
Chris Angelico wrote:
Hence my
query about how variadic functions and automatic currying work - how
does it know whether to curry or run?
Calling it "automatic" was probably a bad choice of words.
I don't mean to imply that Haskell goes around currying
things behind your back when you don't wan
On Thursday, October 6, 2016 at 1:06:07 AM UTC+5:30, BartC wrote:
> On 05/10/2016 14:43, Rustom Mody wrote:
> > On Wednesday, October 5, 2016 at 7:05:02 PM UTC+5:30, BartC wrote:
>
> >> That's the one it can't find. Actually it can't seem to import any
> >> standard libraries, so the implementatio
On Thu, Oct 6, 2016 at 9:45 AM, BartC wrote:
> On 05/10/2016 22:34, Chris Angelico wrote:
>>
>> On Thu, Oct 6, 2016 at 6:35 AM, BartC wrote:
>>>
>>> This is exactly why I persist with my own language implementations. My
>>> current one is only 1/5000th the size but standard libraries are
>>> incl
On 05/10/2016 22:34, Chris Angelico wrote:
On Thu, Oct 6, 2016 at 6:35 AM, BartC wrote:
This is exactly why I persist with my own language implementations. My
current one is only 1/5000th the size but standard libraries are included!)
Yes, it has all the standard library that *you* expect. Do
BartC wrote:
This is exactly why I persist with my own language implementations. My
current one is only 1/5000th the size but standard libraries are included!)
You might like to try a different Haskell implementation,
such as Hugs:
https://wiki.haskell.org/Hugs
According to the web page, it c
On Thu, Oct 6, 2016 at 6:35 AM, BartC wrote:
> This is exactly why I persist with my own language implementations. My
> current one is only 1/5000th the size but standard libraries are included!)
Yes, it has all the standard library that *you* expect. Does it have
what some random person on the i
On 05/10/2016 14:43, Rustom Mody wrote:
On Wednesday, October 5, 2016 at 7:05:02 PM UTC+5:30, BartC wrote:
That's the one it can't find. Actually it can't seem to import any
standard libraries, so the implementation must be screwed up.
Or is it because I downloaded the Minimal** rather Full v
BartC writes:
> On 05/10/2016 11:03, Ben Bacarisse wrote:
>> Gregory Ewing writes:
>>
>>> Steve D'Aprano wrote:
>>>
And (shamelessly using Python syntax) if I have a function:
def spam(x):
print(x)
print(x+1)
spam(time.sleep(60) or 1)
>>>
>>> You can't
On Wednesday, October 5, 2016 at 7:05:02 PM UTC+5:30, BartC wrote:
> On 05/10/2016 14:13, Rustom Mody wrote:
> > On Wednesday, October 5, 2016 at 4:24:01 PM UTC+5:30, BartC wrote:
> >> On 05/10/2016 11:03, Ben Bacarisse wrote:
>
> >>> spam io = do x <- io;
> >>> print x;
> >>>
On Thu, Oct 6, 2016 at 12:13 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> How do you handle variadic functions?
>
>
> All functions in Haskell take exactly one argument, so
> there isn't really any such thing as a variadic function.
> The argument can be a list, however, so you can get t
On 05/10/2016 14:13, Rustom Mody wrote:
On Wednesday, October 5, 2016 at 4:24:01 PM UTC+5:30, BartC wrote:
On 05/10/2016 11:03, Ben Bacarisse wrote:
spam io = do x <- io;
print x;
x <- io;
print (x+1)
(I downloaded Haskell (ghc) yesterday to try this o
Chris Angelico wrote:
So how do you handle something that, by its nature, has BOTH side
effects and a return value?
A Pascal purist would probably say that you should make
it a procedure, and use var parameters to pass back
any results.
In the case of something like the unix write() call, this
On Wednesday, October 5, 2016 at 4:24:01 PM UTC+5:30, BartC wrote:
> On 05/10/2016 11:03, Ben Bacarisse wrote:
> > Gregory Ewing writes:
> >
> >> Steve D'Aprano wrote:
> >>
> >>> And (shamelessly using Python syntax) if I have a function:
> >>>
> >>> def spam(x):
> >>> print(x)
> >>> print
Chris Angelico wrote:
How do you handle variadic functions?
All functions in Haskell take exactly one argument, so
there isn't really any such thing as a variadic function.
The argument can be a list, however, so you can get the
same effect.
--
Greg
--
https://mail.python.org/mailman/listinfo/
On Wednesday, October 5, 2016 at 12:21:35 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Oct 5, 2016 at 5:19 PM, Rustom Mody wrote:
> > Its ironical:
> > - Function in Fortran was meant to emulate math-functions
> > - C took the same thing and did a ‘small little syntax elision’ viz
> > conflating f
On 05/10/2016 11:03, Ben Bacarisse wrote:
Gregory Ewing writes:
Steve D'Aprano wrote:
And (shamelessly using Python syntax) if I have a function:
def spam(x):
print(x)
print(x+1)
spam(time.sleep(60) or 1)
You can't write that in Haskell, because Haskell's
equivalent of print() is
Gregory Ewing writes:
> Steve D'Aprano wrote:
>
>> And (shamelessly using Python syntax) if I have a function:
>>
>> def spam(x):
>> print(x)
>> print(x+1)
>>
>> spam(time.sleep(60) or 1)
>
> You can't write that in Haskell, because Haskell's
> equivalent of print() is not a function (or
Rustom Mody writes:
> On Tuesday, October 4, 2016 at 12:47:58 PM UTC+5:30, dieter wrote:
> ...
>> On the other hand, one can model Python variables as bindings
>> where language constructs (assignments) allow to change the binding.
>>
>> Thus, at an appropriate level of abstraction, you can say
Anuradha Laxminarayan writes:
> it Would be great to stay within the Python world if I could cover
> the key computational monadic ideas without the rest of Haskell.
It's useful to write some Python things in monadic style, but monads
make the most sense as type operators, which don't map onto Py
On Wednesday, 5 October 2016 11:47:17 UTC+5:30, Gregory Ewing wrote:
> Chris Angelico wrote:
> > Seriously though... this ties in with the other issues about *purely*
> > functional languages being rather impractical, and the purity
> > generally being sullied some by things like monads (which I s
On Wed, Oct 5, 2016 at 5:19 PM, Rustom Mody wrote:
> Its ironical:
> - Function in Fortran was meant to emulate math-functions
> - C took the same thing and did a ‘small little syntax elision’ viz
> conflating function and subprogram (procedure in Pascal speak) all under
> the heading of function.
On Wed, Oct 5, 2016 at 5:17 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> Seriously though... this ties in with the other issues about *purely*
>> functional languages being rather impractical, and the purity
>> generally being sullied some by things like monads (which I still
>> don't un
On Wednesday, October 5, 2016 at 11:34:31 AM UTC+5:30, Gregory Ewing wrote:
> Steve D'Aprano wrote:
>
> > And (shamelessly using Python syntax) if I have a function:
> >
> > def spam(x):
> > print(x)
> > print(x+1)
> >
> > spam(time.sleep(60) or 1)
>
> You can't write that in Haskell,
Chris Angelico wrote:
Seriously though... this ties in with the other issues about *purely*
functional languages being rather impractical, and the purity
generally being sullied some by things like monads (which I still
don't understand, despite the explanations in another thread).
If you'd lik
Chris Angelico wrote:
So what
happens if you have a monad "print to the console" in place of Steve's
time.sleep example? Will you get one execution of it or two?
Again, you wouldn't be able to write it that way in Haskell.
The things you *would* be able to write would all have the
property tha
Steve D'Aprano wrote:
And (shamelessly using Python syntax) if I have a function:
def spam(x):
print(x)
print(x+1)
>
> spam(time.sleep(60) or 1)
You can't write that in Haskell, because Haskell's
equivalent of print() is not a function (or at least
it's not a function that ever return
On Wednesday, October 5, 2016 at 6:22:45 AM UTC+5:30, Steve D'Aprano wrote:
> On Wed, 5 Oct 2016 04:12 am, Rustom Mody wrote:
>
> > On Tuesday, October 4, 2016 at 10:06:00 PM UTC+5:30, Steve D'Aprano wrote:
> >> On Tue, 4 Oct 2016 09:32 pm, Rustom Mody wrote:
> >>
> >> > Are not the contents of t
On Wed, 5 Oct 2016 04:12 am, Rustom Mody wrote:
> On Tuesday, October 4, 2016 at 10:06:00 PM UTC+5:30, Steve D'Aprano wrote:
>> On Tue, 4 Oct 2016 09:32 pm, Rustom Mody wrote:
>>
>> > Are not the contents of the scope and the shape of the scope different
>> > things?
>>
>>
>> What does "the sha
On Wed, 5 Oct 2016 06:10 am, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Tue, 4 Oct 2016 11:27 pm, Ben Bacarisse wrote:
>>
>>> Haskell defines let (it's version of multiple mutually recursive
>>> bindings) in terms of the least fix point of a lambda function whose
>>> (pattern) parameter bin
Ben Bacarisse :
> The question came up because (I paraphrase) "even Scheme uses
> assignment to explain mutually recursive definitions". Haskell defines
> them using the fixed point operator. It's not really about Haskell
> programs so much as how the language features are defined.
BTW, here's the
Steve D'Aprano writes:
> On Tue, 4 Oct 2016 11:27 pm, Ben Bacarisse wrote:
>
>> Haskell defines let (it's version of multiple mutually recursive
>> bindings) in terms of the least fix point of a lambda function whose
>> (pattern) parameter binds the expressions in the definitions.
>
> It binds *t
On Wed, Oct 5, 2016 at 6:10 AM, Marko Rauhamaa wrote:
> A truly functional programming language wouldn't have side effects (in
> this case, it wouldn't sleep).
That makes sense. When people are sleeping, they're non-functional,
ergo a programming language that can sleep is non-functional :)
Seri
Steve D'Aprano :
> On Tue, 4 Oct 2016 11:27 pm, Ben Bacarisse wrote:
>
>> Haskell defines let (it's version of multiple mutually recursive
>> bindings) in terms of the least fix point of a lambda function whose
>> (pattern) parameter binds the expressions in the definitions.
>
> It binds *the expr
On Tuesday, October 4, 2016 at 10:15:10 PM UTC+5:30, Steve D'Aprano wrote:
> On Tue, 4 Oct 2016 11:27 pm, Ben Bacarisse wrote:
>
> > Haskell defines let (it's version of multiple mutually recursive
> > bindings) in terms of the least fix point of a lambda function whose
> > (pattern) parameter bin
On Tuesday, October 4, 2016 at 10:06:00 PM UTC+5:30, Steve D'Aprano wrote:
> On Tue, 4 Oct 2016 09:32 pm, Rustom Mody wrote:
>
> > Are not the contents of the scope and the shape of the scope different
> > things?
>
>
> What does "the shape of the scope" mean?
>
> Scopes don't have a shape -- t
On Tue, 4 Oct 2016 11:27 pm, Ben Bacarisse wrote:
> Haskell defines let (it's version of multiple mutually recursive
> bindings) in terms of the least fix point of a lambda function whose
> (pattern) parameter binds the expressions in the definitions.
It binds *the expression* itself? Not the val
On Tue, 4 Oct 2016 09:32 pm, Rustom Mody wrote:
> Are not the contents of the scope and the shape of the scope different
> things?
What does "the shape of the scope" mean?
Scopes don't have a shape -- they aren't geometric objects. So I'm afraid I
don't understand what distinction you are tryin
Marko Rauhamaa writes:
> dieter :
>> The concept "assignment" comes from an operational semantics based on
>> some form of "RAM" machine. Such a machine has storage cells where you
>> can assign values to which remain there until overridden with a new
>> value.
>>
>> The concept "binding" comes f
Rustom Mody :
> You are scorning something basic: Dont like 'binding'?
> Ok what about stack-frames? Activation-records?
>
> Just had a conversation with a colleague yesterday in which he was
> complaining about how hard students find to learn this stuff because
> of confusions like hardware-stack
On Tuesday, October 4, 2016 at 2:05:31 PM UTC+5:30, Marko Rauhamaa wrote:
> dieter :
> > The concept "assignment" comes from an operational semantics based on
> > some form of "RAM" machine. Such a machine has storage cells where you
> > can assign values to which remain there until overridden with
On Tuesday, October 4, 2016 at 12:47:58 PM UTC+5:30, dieter wrote:
> Steve D'Aprano writes:
> > On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
> >> Steve D'Aprano writes:
> >>> Why shouldn't people say that binding and assignment are the same
> >>> thing in Python? What's the difference?
>
dieter :
> The concept "assignment" comes from an operational semantics based on
> some form of "RAM" machine. Such a machine has storage cells where you
> can assign values to which remain there until overridden with a new
> value.
>
> The concept "binding" comes from a denotational semantics base
Steve D'Aprano writes:
> On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
>> Steve D'Aprano writes:
>>> Why shouldn't people say that binding and assignment are the same
>>> thing in Python? What's the difference?
>>
>> Outside Python, (lambda x : f(x)) is said to "bind" x. It's different
>>
On Tuesday, October 4, 2016 at 8:11:41 AM UTC+5:30, Steve D'Aprano wrote:
> On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
>
> > Steve D'Aprano writes:
> >> Why shouldn't people say that binding and assignment are the same
> >> thing in Python? What's the difference?
> >
> > Outside Python
On Mon, 3 Oct 2016 04:15 pm, Jussi Piitulainen wrote:
> Steve D'Aprano writes:
>> Why shouldn't people say that binding and assignment are the same
>> thing in Python? What's the difference?
>
> Outside Python, (lambda x : f(x)) is said to "bind" x. It's different
> from assigning a new value to
79 matches
Mail list logo
