From: Noah Lavine <noah.b.lavine@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Compiler Branch
Date: Sun, 8 Jan 2012 16:15:47 -0500 [thread overview]
Message-ID: <CA+U71=OLUU+w8eOMaJdWByBWa9U3wtLKvOO0ngWAySJ-3bjQrg@mail.gmail.com> (raw)
In-Reply-To: <877h12dz5a.fsf@pobox.com>
Hello,
> Interesting. `verify' seems to be a form of contracts:
>
> http://ftp.ccs.northeastern.edu/scheme/pubs/icfp2002-ff.pdf
>
> Does `verify' have runtime semantics? Under what situations, if any,
> would the compiler insert runtime checks?
It has no runtime semantics right now. I considered making it like
'assert', but I'm not sure that's right. I will look at that paper.
> As that paper indicates, two issues you will have to deal with are
> higher-order functions and blame.
>
> Your interest in static analysis naturally raises the question of types.
> You might like this paper:
>
> http://www.ccs.neu.edu/racket/pubs/dls06-tf.pdf
I will look at that too; thank you.
> Ah, I was just curious. I made some small changes relative to
> stable-2.0 (primcall and seq), and wondered if they were a good idea or
> not.
>
> I was also considering a move to a CPS-based intermediate language.
> Some links are here:
>
> http://wingolog.org/archives/2011/07/12/static-single-assignment-for-functional-programmers
Oh, this is interesting. I was just wondering if I needed a CPS-type
representation to write the analyzer reasonably elegantly. If you
think the main compiler also needs it, then perhaps I should work on
that first, and then come back to the analyzer question.
I do think there's a problem with plain CPS, though - it forces you to
pick an order for the evaluation of function arguments. I would like
to use CPS with some sort of parallel-call operator, so we can leave
the order undefined (maybe at some point an optimizer will want to
adjust the order). What do you think?
I also noticed that at the end of that blog post you said you were
considering ANF versus CPS for Guile (I assume you'd already decided
that you didn't like Tree-IL). Does this mean you decided on CPS?
>> My first idea was to implement something equivalent to 0-CFA, which
>> unfortunately has complexity O(n^3). If there's something that's
>> faster and still produces useful results, that could be a good first
>> step. However, I also think we could get the average-case time far
>> below n^3 by doing inference on demand instead of calculating the type
>> of every binding, similar to the change that peval went through a
>> couple months ago.
>
> Yes, this is my thought as well. Note also that peval is described by
> waddell and dybvig as being a kind of special-purpose sub-0CFA.
That makes sense. What I'd *really* like to do is make the analyzer
use the same on-demand-calculation infrastructure as peval, but it
might be really tricky to make them fit together. I am planning to
leave that project for much later.
Noah
next prev parent reply other threads:[~2012-01-08 21:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 4:39 Compiler Branch Noah Lavine
2011-12-13 8:47 ` Andy Wingo
2011-12-13 13:52 ` Noah Lavine
2012-01-07 1:00 ` Andy Wingo
2012-01-08 0:42 ` Noah Lavine
2012-01-08 14:53 ` Andy Wingo
2012-01-08 21:15 ` Noah Lavine [this message]
2012-01-20 20:49 ` Andy Wingo
2011-12-18 20:42 ` Ludovic Courtès
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='CA+U71=OLUU+w8eOMaJdWByBWa9U3wtLKvOO0ngWAySJ-3bjQrg@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/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).