From: tantalum <sph@posteo.eu>
To: Guile user <guile-user@gnu.org>
Subject: Re: C programs in Scheme syntax
Date: Sun, 31 May 2020 15:40:03 +0000 [thread overview]
Message-ID: <a0c75ad08cc2ec802934d85eab8533c7@posteo.de> (raw)
ive started https://github.com/sph-mn/sph-sc and have been using it a
lot over the years and worked through several c edge cases. i enjoy
using it, more and more even. the git repository page contains several
hints and ideas on the general topic. i you have any questions, i'd be
happy to answer them.
a few key points about sc:
* it uses scheme read to parse code but that discards scheme comments
and other ways to insert c comments are needed. using guile-reader
instead works, but it is a c library to be compiled by the user and i
often faced autotools issues with it
* i guess it would be possible to do the whole generation process via
scheme macros. it might be better than the approach currently
implemented in sc, as the scheme macro system and scheme comments are
immediately available. syntax checks with hints on error would be nice.
the translation process of sc calls procedures for all elements of the
nested list of expressions returned by scheme read. first going through
the tree top to bottom - possibly translating whole subtrees to c
strings or returning sc to be parsed again, then bottom to top to handle
remaining elements - elements which might be lists with arguments that
have been previously translated. sescript, the javascript variant of sc,
uses hashtables that map s-expression prefixes to replacer functions,
which is easier to extend than the case statements used by sc
* the reason why i havent implemented a scheme style macro system for sc
yet is that the task of implementing something like syntax-rules or
syntax-case seems quite daunting. a good pattern matcher and preserving
hygiene seem to be the top issues. simpler macro systems are possible,
quickly implemented even, but all in all i havent hit a clear need for
it yet (still thinking what i would do with it) and fear that it might
create hard to read c code. then again, it might simplify c code because
of a reduced dependence on the preprocessor
* sc has automated tests with input/output listed, this could be helpful
for finding edge cases even in other projects
* with s-expressions, automated code documentation for c becomes easier
than ever before
next reply other threads:[~2020-05-31 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-31 15:40 tantalum [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-05-29 3:23 C programs in Scheme syntax Keith Wright
2020-05-29 3:57 ` John Cowan
2020-05-29 7:29 ` Arne Babenhauserheide
2020-05-29 12:34 ` Matt Wette
2020-05-29 15:30 ` Zelphir Kaltstahl
2020-05-29 16:27 ` Andrew Gwozdziewycz
2020-05-29 20:01 ` Jan Wedekind
2020-05-30 10:13 ` Todor Kondić
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=a0c75ad08cc2ec802934d85eab8533c7@posteo.de \
--to=sph@posteo.eu \
--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).