From: Michael Lucy <MichaelGLucy@Gmail.com>
To: guile-devel@gnu.org
Subject: PEG Parser Updates/Questions
Date: Wed, 28 Jul 2010 00:13:44 -0500 [thread overview]
Message-ID: <AANLkTi=U+14pSWomQvxzN8SaVGfu_nVn-3d1fqTXmv2v@mail.gmail.com> (raw)
I've officially eliminated the last define-macro expression.
However, I get the feeling that things may not be exactly as desired.
The original program made extensive use of functions in building the
macros, and I originally tried to replace these with macros. This
turned out to be a little difficult to debug, however (read: I was
unable to make the code actually work). I eventually abandoned this
and just made datum->syntax calls.
On the one hand, this works. I also find it easier to debug, and I
think it looks cleaner.
The downside is that one doesn't get all the same benefits of
referential transparency, so I still have gensyms in the functions
etc. Is this a problem?
If so, I can definitely replace everything with macros, but I might
not be able to do that and get everything else done by the GSOC
project deadline. I'd like to hang around after the project is
officially done from Google's point of view to polish things up, so I
could also do it then.
Another question about module namespaces: I have some syntax that I'd
like to be available to code generated by macros in my module, but
which I'd rather not export to the user (to avoid clobbering their
functions). Is there a standard way of doing this? I can't seem to
find anything in the module documentation regarding giving namespaces
to things in modules except for :renamer, which has to be done by the
user--the only options appear to be not exporting it at all, or
exporting it straight into the user's namespace. The best fix I can
think of is naming the syntax things the user is unlikely to ever take
(or maybe using gensyms to make sure it isn't a name they take).
next reply other threads:[~2010-07-28 5:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 5:13 Michael Lucy [this message]
2010-07-28 5:41 ` PEG Parser Updates/Questions No Itisnt
2010-07-28 5:51 ` Michael Lucy
2010-08-06 6:40 ` Michael Lucy
2010-08-16 5:37 ` Michael Lucy
2010-08-20 21:30 ` Andy Wingo
2010-08-29 7:45 ` Phil
2010-08-30 15:32 ` Andy Wingo
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='AANLkTi=U+14pSWomQvxzN8SaVGfu_nVn-3d1fqTXmv2v@mail.gmail.com' \
--to=michaelglucy@gmail.com \
--cc=guile-devel@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).