On Wed, Aug 26, 2015 at 03:55:15PM +0300, Oleg Grenrus wrote:
> It’s not re-assigment, it’s rather feature request for non-rec-let
> (as let in Haskell is recursive)
> and some pragma to say “yes, I do shadow name on purpose"
Ah, I see. Still I feel that, as much as it is easily rewriteable to a
`lambda (etc etc` (which will shadow the first `a`)
IMO, having <- in do syntax look like assignment is bad enough as it is,
no need to further enforce the illusion.
The variable shadowing that effectively occurs in that example is still
just as bad as regular shadowing.
On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote:
> Hi all,
> I'd like to propose an inbuilt "assignment" operator for use within do-blocks.
> Here's a common pattern -
> foo <- someaction
> do something with foo
> -- Here we "update" the value of foo
> let foo' = bar foo
> -- The code from this point onwards shouldn't use foo
> -- but there is no way to enforce that
> What I'd like to do instead is something like -
> let foo = bar foo
> But to Haskell this is a recursive definition instead of an update to
> the previous value.
> I can do this instead -
> foo <- return $ bar foo
> which works fine but (I assume) GHC currently can't optimise it for
> arbitrary monads. Also it won't necessarily work if the monad laws
> don't hold.
> It would be nice to have an "assignment arrow", say (<-=), which lets
> GHC optimise this, so -
> foo <-= bar foo
> desugars to something like -
> foo' (bar foo)
> foo' foo = ...
> -- Anupam
> Haskell-Cafe mailing list
> [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
On Wed, Aug 26, 2015 at 6:04 PM, Francesco Ariis <[hidden email]> wrote:
> On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote:
>> Hi all,
>> I'd like to propose an inbuilt "assignment" operator for use within
> Time to add your proposal here!
I just requested access to the wiki.
> Honestly, I feel it would break the way I read Haskell programs
> (i.e. no reassignment surprises).
> On Wed, Aug 26, 2015 at 7:25 PM, Anupam Jain <[hidden email]> wrote:
>> What I'd like to do instead is something like -
>> let foo = bar foo
>> But to Haskell this is a recursive definition instead of an update to
>> the previous value.
> This is a chestnut at least two years old. Last time I remember, the
> discussion frothed under the rubric of "non-recursive let":
Thanks for linking to that discussion. However that discussion seems
to be revolving around the non-recursive let. What I propose is only
an extension to the do-notation desugaring, which seems more benign.
On Wed, Aug 26, 2015 at 8:14 PM, Tobias Dammers <[hidden email]> wrote:
> IMO, having <- in do syntax look like assignment is bad enough as it is,
> no need to further enforce the illusion.
The syntax could be anything, it doesn't have to be an arrow. For
example it could simply be an inbuilt function say `liftIdentity`.
foo <- liftIdentity $ bar foo
This makes sense if we think of every monad as a transformer around
the Identity monad. Analogous to liftIO, except automatically defined
for all Monads. Of course GHC would have to implement it in such a way
so as to not use `return`.
> The variable shadowing that effectively occurs in that example is still
> just as bad as regular shadowing.
Thank you for taking time to add your proposal and peace be upon
William Yager for coming up with the List of Nitpicks, having them
in one place is a great way to assess the issues in an organic manner.
> Looking at the nitpick list, I just remembered that there was a
> discussion about making let optional in do bindings a couple of years ago.
> https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102741.html >
> One of the major stumbling points was how recursive bindings should
> work. These these two proposals would combine nicely.
> adding a statement
> pat = exp
> that expresses a non-recursive let.
Exactly! +1 from me.
Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden