Re: [Haskell-cafe] Alternative name for return

2013-08-06 Thread J. Stutterheim
Thanks Chris. Yes, I like lift as well, because I find it a rather intuitive 
name. Unfortunately, as you say, it is already a commonly used name as well, 
which might make it slightly confusing.

When I hear `unit` I immediately think about generic programming, not so much 
about monads. Can you perhaps explain the intuition behind `unit` as an 
alternative to `return` in the context of monads?

- Jurriën

On 6 Aug 2013, at 07:32, Christian Sternagel c.sterna...@gmail.com wrote:

 Dear Jurriën.
 
 personally, I like lift (which is of course already occupied in Haskell), 
 since an arbitrary value is lifted into a monad. (The literature sometimes 
 uses unit.)
 
 cheers
 
 chris
 
 On 08/06/2013 02:14 PM, J. Stutterheim wrote:
 Dear Cafe,
 
 
 Suppose we now have the opportunity to change the name of the `return` 
 function in Monad, what would be a better  name for it? (for some 
 definition of better)
 
 N.B. I am _not_ proposing that we actually change the name of `return`. I do 
 currently have the opportunity to pick names for common functions in a 
 non-Haskell related project, so I was wondering if there perhaps is a better 
 name for `return`.
 
 
 - Jurriën
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Alternative name for return

2013-08-06 Thread J. Stutterheim
Hi Tarik,

Could you motivate the choice for these names? Thanks!

On 6 Aug 2013, at 08:14, Tarik ÖZKANLI tozkanli2...@gmail.com wrote:

 next, carry, feed, roll
 
 
 
 On 6 August 2013 08:37, KC kc1...@gmail.com wrote:
 I thought a pure value was being returned from the monad. :)
 
 
 On Mon, Aug 5, 2013 at 10:32 PM, Christian Sternagel c.sterna...@gmail.com 
 wrote:
 Dear Jurriën.
 
 personally, I like lift (which is of course already occupied in Haskell), 
 since an arbitrary value is lifted into a monad. (The literature sometimes 
 uses unit.)
 
 cheers
 
 chris
 
 
 On 08/06/2013 02:14 PM, J. Stutterheim wrote:
 Dear Cafe,
 
 
 Suppose we now have the opportunity to change the name of the `return` 
 function in Monad, what would be a better  name for it? (for some 
 definition of better)
 
 N.B. I am _not_ proposing that we actually change the name of `return`. I do 
 currently have the opportunity to pick names for common functions in a 
 non-Haskell related project, so I was wondering if there perhaps is a better 
 name for `return`.
 
 
 - Jurriën
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 
 -- 
 --
 Regards,
 KC
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Alternative name for return

2013-08-06 Thread J. Stutterheim
I have to admit that I am a bit torn about using `pure`. On the one hand, if 
you actually have a pure value, it feels pretty intuitive to me. But what about

  pure (putStrLn Hi)

`putStrLn Hi` is not a pure value... Or is there another way to interpret the 
word pure in this context?

As for Applicative, I can add (and have added) the Applicative constraint in 
the Monad definition for my project, so I will also have to write an 
Applicative instance for my monads.


- Jurriën

On 6 Aug 2013, at 09:50, Erik Hesselink hessel...@gmail.com wrote:

 What about `pure`? It's already used in applicative, and has the
 motivation that it's embedding a pure value in some context. Since I
 don't know the details of your project, I don't know if you need two
 names (one for the applicative version, and one for the monadic
 version).
 
 Erik
 
 On Tue, Aug 6, 2013 at 7:14 AM, J. Stutterheim j.stutterh...@me.com wrote:
 Dear Cafe,
 
 
 Suppose we now have the opportunity to change the name of the `return` 
 function in Monad, what would be a better  name for it? (for some 
 definition of better)
 
 N.B. I am _not_ proposing that we actually change the name of `return`. I do 
 currently have the opportunity to pick names for common functions in a 
 non-Haskell related project, so I was wondering if there perhaps is a better 
 name for `return`.
 
 
 - Jurriën
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Alternative name for return

2013-08-06 Thread J. Stutterheim
Hi Adam,

Thank you for an interesting thought; an invisible name might actually be on of 
the better solutions, although you are right in that your suggestion is a bit 
too open for my current project.

Actually, I believe that naming is very important. My goal is to have the 
average programmer (i.e. someone without a post-bachelor degree) look at the 
code and get an intuitive feel of what is going on. So in reply to Jerzy, I do 
want to encourage the discussion in the Noble Domain of Philosophy and I also 
want to repeat that I am not proposing to change Haskell or Haskell libraries 
(I am working with another language altogether), so don't fear ;)


- Jurriën

On 6 Aug 2013, at 10:46, Adam Gundry adam.gun...@strath.ac.uk wrote:

 Hi,
 
 On 06/08/13 06:14, J. Stutterheim wrote:
 Suppose we now have the opportunity to change the name of the
 `return` function in Monad, what would be a better  name for it?
 (for some definition of better)
 
 Rather than proposing a different name, I'm going to challenge the
 premise of your question. Perhaps it would be better if `return` had no
 name at all. Consider the following:
 
return f `ap` s `ap` t
 
f $ s * t
 
do { sv - s
   ; tv - t
   ; return (f sv tv) }
 
 These are all different ways of spelling
 
f s t
 
 plus the necessary applicative or monadic bureaucracy. But why couldn't
 we write just the plain application, and let the type system deal with
 the plumbing of effects?
 
 I realise that this may be too open a research area for your project...
 
 
 N.B. I am _not_ proposing that we actually change the name of
 `return`. I do currently have the opportunity to pick names for
 common functions in a non-Haskell related project, so I was wondering
 if there perhaps is a better name for `return`.
 
 I don't think the choice of name matters. I do think it should be short.
 Preferably invisible.
 
 Adam



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Alternative name for return

2013-08-06 Thread J. Stutterheim
That argument makes sense, although I find it a bit counter-intuitive still. If 
I saw the function `pure` for the first time, my first impression (however 
wrong it may be) would be that it takes a pure value (regardless of context) 
and does something with it. Applying `pure` to an IO operation goes against 
that intuition.

Looking at the type of `return :: a - m a, there are several slightly more 
intuitive (to me) options in this discussion already:

lift: the value `a` is lifted into the monad `m`
pack: the value `a` is packed into the monad `m`
wrap: the value `a` is wrapped in the monad `m`
inject: the value `a` is injected into the monad `m`
promote: the value `a` is promoted to a monad `m a`


On 6 Aug 2013, at 10:16, Tobias Dammers tdamm...@gmail.com wrote:

 It is a pure value in the context of the outer monad (the one you wrap it 
 in). I'd say pure is still appropriate.
 
 On Aug 6, 2013 10:14 AM, Tom Ellis 
 tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
 On Tue, Aug 06, 2013 at 10:03:04AM +0200, J. Stutterheim wrote:
  `putStrLn Hi` is not a pure value...
 
 Why not?
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Alternative name for return

2013-08-05 Thread J. Stutterheim
Dear Cafe,


Suppose we now have the opportunity to change the name of the `return` function 
in Monad, what would be a better  name for it? (for some definition of better)

N.B. I am _not_ proposing that we actually change the name of `return`. I do 
currently have the opportunity to pick names for common functions in a 
non-Haskell related project, so I was wondering if there perhaps is a better 
name for `return`.


- Jurriën
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

2013-07-15 Thread J. Stutterheim
The IDE still works for Windows, but it isn't actively developed anymore (though bugs and minor annoyances are still being fixed). For Mac and Linux we now have a command line tool that uses the IDE's codebase. Personally, I just use vim (of course you can use any editor you prefer; vim comes with syntax colouring for Clean out of the box) for coding and then use a new CLI tool called CPM (Clean Project Manager) to build my project. This tool will be included by default with the next Clean release. I doubt the IDE will be resurrected on Mac and Linux, because it is just too much work to port Object IO (the GUI library) to those platforms and our own Mac/Linux users strongly prefer their own editors over the IDE anyway. For people that prefer a non-CLI workflow, we are actually looking into making a web-based IDE in iTasks (although it doesn't have a very high priority at the moment).The OS dependency for dynamics stems from the fact that the Clean dynamics are quite a bit more powerful than Haskell's. For example, using dynamics, it is possible to send arbitrary functions to another Clean application, which can then dynamically link these functions in at runtime and immediately execute them. It doesn't even need to be the same program, which Cloud Haskell does require(and theoretically, it can even be another OS). This advanced dynamic linking feature requires intimate knowledge of the target OS' binary representation. (I would actually really like to see Haskell's dynamics system to become as powerful as Clean's; it also supports polymorphism, for example)On Jul 15, 2013, at 04:31 AM, "Richard A. O'Keefe" o...@cs.otago.ac.nz wrote: On 13/07/2013, at 11:27 PM, J. Stutterheim wrote:- they then abandoned the Macintosh world forWindows. The Mac IDE was killed off; there isnow an IDE for Windows but not MacOS or Linux.The good news is that the latest version of Clean[2] and its code generator[3] now works fine again on 64 bit Mac OS X Is that still the command-line tools, or has the IDE been resurrected? - other major features remain Windows-onlyThe bad news is that this is true to some extend; the dynamics system is still largely Windows-only. However, this is the only language feature I can think of that really is Windows-only. I have never been able to understand why there should be ANY OS-dependency in the dynamics feature. - the available books about Clean are way out ofdate, several drafts of other books remainincomplete.- the documentation (like the Report) has always beenrather amateurish and incomplete. Certainlycompared with the Haskell documentation.An iTasks book is actually in the works, which will contain a fair bit of Clean (although it is not a dedicated Clean book). There are also concrete plans to update the language manual soon-ish. Not to be offensive, because after saying "Denk U" I have no more Dutch words I can use, but it would really pay to find a native speaker of English to give the manual a final polish.- there is nothing to compare with the Haskell Platform.Actually, yes there is[4]. A misundertanding. "Nothing to compare with" is idiomatic for "nothing of comparable size to". Yes, you _can_ compare the Clean Platform with the Haskell Platform; it's a lot smaller. It can be described as a mix between Haskell Platform and a mini Hackage-like repository. There is no such thing as a Clean alternative to cabal install, though.Keep in mind that there is only a handful of people working on Clean, while Haskell has a huge community in comparison. Haskell has always benefited from - openness - multiple implementations - documentation ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

2013-07-13 Thread J. Stutterheim
I currently work at the Radboud University where Clean is being developed. As 
such, I use it daily. Coming from Haskell, I have to admit that I never really 
got used to the let-before syntax, exactly for the reasons described in the 
previous emails. However, it does have some merit. In combination with 
uniqueness typing, the compiler can do destructive updates on the variables in 
the let-before blocks, making the generated code more efficient.

Possibly a bit off-topic, but please allow me to give an update about the 
latest status of Clean (mixed with some personal opinion ;)

 Clean is relatively unknown because
 - they started in the Macintosh world, and when
   they provided a compiler for the Unix world,
   they did not port their modern graphics and
   I/O library to it.  So you could never write
   a program that would run on Macs and other things.

Object IO (the graphics library) will probably never work for systems other 
than Windows because f low priority and a lack of manpower. This is admittedly 
unfortunate if you want to write native client-side GUIs. Currently, most of 
Clean's progress is driven by the iTask System[1], which provides a web GUI.

 - they then abandoned the Macintosh world for
   Windows.  The Mac IDE was killed off; there is
   now an IDE for Windows but not MacOS or Linux.

The good news is that the latest version of Clean[2] and its code generator[3] 
now works fine again on 64 bit Mac OS X (I would rate it as advanced beta, or 
perhaps even RC quality). Linux 64 support is currently being stabilised 
(currently alpha quality). Hopefully we will be able to create a new Clean 
release for Mac OS X, Linux and Windows this year. It will then also contain a 
command-line based build tool for Clean IDE project files.

 - other major features remain Windows-only

The bad news is that this is true to some extend; the dynamics system is still 
largely Windows-only. However, this is the only language feature I can think of 
that really is Windows-only.

 - the change from Clean 1.3 to Clean 2 was huge,
   like I mentioned above, none of my code survived
   the change, and there was at that time no
   conversion program

Warning, personal opinion ahead: that's the price of progress I suppose :) 
Because Clean has a very small user base, the language itself is still 
evolving, and there is no release schedule of any kind, it doesn't really pay 
to have a complicated deprecation process.

 - the available books about Clean are way out of
   date, several drafts of other books remain
   incomplete.
 - the documentation (like the Report) has always been
   rather amateurish and incomplete.  Certainly
   compared with the Haskell documentation.

An iTasks book is actually in the works, which will contain a fair bit of Clean 
(although it is not a dedicated Clean book). There are also concrete plans to 
update the language manual soon-ish.

 - there is nothing to compare with the Haskell Platform.

Actually, yes there is[4]. It can be described as a mix between Haskell 
Platform and a mini Hackage-like repository. There is no such thing as a Clean 
alternative to cabal install, though.

Keep in mind that there is only a handful of people working on Clean, while 
Haskell has a huge community in comparison. This makes it hard to keep up with 
advanced language features.


- Jurriën

[1] http://wiki.clean.cs.ru.nl/ITasks
[2] https://svn.cs.ru.nl/cgi-bin/admin/info/clean-compiler
[3] https://svn.cs.ru.nl/cgi-bin/admin/info/clean-code-generator
[4] https://svn.cs.ru.nl/cgi-bin/admin/info/clean-platform
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe