From: taylanbayirli@gmail.com (Taylan Ulrich B.)
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: "guile-user@gnu.org" <guile-user@gnu.org>,
Dmitry Bogatov <KAction@gnu.org>
Subject: Re: Syntax-rules generate symbol
Date: Tue, 10 Sep 2013 11:16:12 +0200 [thread overview]
Message-ID: <87bo41hw9v.fsf@taylan.uni.cx> (raw)
In-Reply-To: <CAMFYt2Zc8gSGyUhvjS404qFB0Xwhe=7OB_Hv-te9wFbXWi1VfA@mail.gmail.com> (Panicz Maciej Godek's message of "Tue, 10 Sep 2013 08:11:09 +0200")
Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> I assume that the main reason for using this is efficiency (rather
> than simplicity), because allegedly guile's continuations are rather
> inefficient.
>
> On one hand, it's good to know that (and would be even better
> to be able to find it out by skimming section 6.13 of the manual),
> but on the other it would be nicer if the compiler could trace the
> usages of continuations and figure out whether a given one is
> ever being re-entered, and optimize accordingly.
Delimited/composable continuations don't have the efficiency problems of
call/cc (some of which are inherent, and not related to Guile, from what
I know), and I'd urge anyone to read the following critique of call/cc
revealing other problems with it as well. :)
http://okmij.org/ftp/continuations/against-callcc.html
Guile supports "prompts" as the primitive behind higher-level delimited
continuation operators, escape continuations, exceptions, etc. The
relevant manual section is a nice read, though it might require more
than a quick skim: (info "(guile) Prompts")
The compiler might be able to optimize some usages of call/cc into the
more efficient use of a delimited continuation, but after reading about
call/cc and delimited continuations, it becomes a rather blurry line
(IMO) which generalizes which, and on the meanwhile I find it most nice
to use the abstraction that expresses the actual idea as directly as
possible. And since breaking from a loop or returning from a block are
inherently escape-only actions, I think it's actually nicer to use
`let/ec' for those cases even in terms of code clarity etc.
next prev parent reply other threads:[~2013-09-10 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 16:19 Syntax-rules generate symbol Dmitry Bogatov
2013-09-09 16:59 ` Panicz Maciej Godek
2013-09-09 20:03 ` Taylan Ulrich B.
2013-09-10 6:11 ` Panicz Maciej Godek
2013-09-10 9:16 ` Taylan Ulrich B. [this message]
2013-09-10 10:38 ` Ian Price
2013-09-10 10:33 ` Ian Price
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=87bo41hw9v.fsf@taylan.uni.cx \
--to=taylanbayirli@gmail.com \
--cc=KAction@gnu.org \
--cc=godek.maciek@gmail.com \
--cc=guile-user@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).