From: Ian Price <ianprice90@googlemail.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-user@gnu.org
Subject: Re: prompts: any example ?
Date: Wed, 07 Mar 2012 12:54:02 +0000 [thread overview]
Message-ID: <871up4zi51.fsf@Kagami.home> (raw)
In-Reply-To: <87r4x967by.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 03 Mar 2012 16:18:57 +0100")
ludo@gnu.org (Ludovic Courtès) writes:
> Hi Ian,
>
> Excellent illustration, thank you!
>
> Ian Price <ianprice90@googlemail.com> skribis:
>
>> https://gist.github.com/1548531 - monadic reflection
>
> Could you expound on this one? I can feel the greatness, but I don’t
> fully grasp it. :-)
Yes, and it doesn't help that it is missing a bunch of helpers :) I no
longer have the original file, so I can't even remember if I stomped out
the bugs in it(probably not).
The trick comes from, I think, Filinski's "Representing Monads",
although it has been quite a while since I've read it. Instead of monads
being represented by the usual 'bind' and 'unit' functions, or the
(categorical?) definition of 'unit', 'fmap', 'join', they are instead
represented by two operators 'reflect' and 'reify'.
reify : (() -> a) -> m a
reflect : m a -> a
reify takes a function that returns a value, and returns a monadic
value i.e. it lifts a pure expression to an effectful one.
reflect takes a monadic value and returns the value. i.e. it lowers the
effectful value into the pure layer.
This representation has two nice properties. Firstly, we get direct
style back :-). This one is important to me, and reflects the
fundamental reason why we need continuations: To rescue us from the
horror of forced styles :).
The second one, which I don't think he mentioned in that paper (maybe
in "representing layered monads"?) is that tagged delimited
continuations actually allow us to use multiple monads quite naturally,
without the need to invent things like monad transformers. In that
example, I quite naturally mix the reader and state monads.
It isn't quite perfect: the 'do-rename' function is not pretty, some
functions like 'with-extended-environment' need to take a thunk, and
without inference we need a different named reflect/reify for each
monad, but it seems relatively useful and I was quite obsessed with it
for a time.
--
Ian Price
"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"
next prev parent reply other threads:[~2012-03-07 12:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 21:32 prompts: any example ? Catonano
2012-03-03 8:08 ` Ian Price
2012-03-03 15:18 ` Ludovic Courtès
2012-03-07 12:54 ` Ian Price [this message]
2012-03-08 18:27 ` Ian Price
2016-08-22 12:51 ` Catonano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871up4zi51.fsf@Kagami.home \
--to=ianprice90@googlemail.com \
--cc=guile-user@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).