unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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.



  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).