public inbox for
 help / color / mirror / Atom feed
From: Arvydas Silanskas <>
To: kawa mailing list <>
Subject: Kawa source tree organization
Date: Sun, 22 Nov 2020 02:23:45 +0200	[thread overview]
Message-ID: <> (raw)

Good evening,

I've been digging around kawa source tree a few times, and frankly it feels
abit overwhelming to get into happy-hacking of its internals. Not really
because of code itself, but because of all peripheral code sitting in one
place. Things that depend on servlets, jline, echo2, swt, domterm, etc,
don't really have significance to the implementation of the core, but they
do add mental and menial library imports overhead to get the whole thing

Perhaps it could be worthwhile splitting things up? For example:

* kawa-the-compiler base project, that'd consist basically of
language-agnostic compiler what now are gnu.bytecode, gnu.expr, etc.
Ideally one could just use it to create a jvm targeting language.
* kawa-the-scheme project, which would be what implements the minimal core
scheme, such as the native syntax forms seen in kawa.lang package. Depends
on kawa-the-compiler project. Ideally one could just use it as a
self-sufficient minimal scheme library.
* various feature-projects, that depend on either just kawa-the-compiler,
or kawa-the-scheme, but not on other feature-projects.
* the main kawa project, which includes everything listed above, implements
the public static main, and handles command line arguments. Basically, the
module that compiles to what now is kawa.jar.

What do you think? In terms of actual ways of implementing this, I'd like
to see maven or gradle used, but git submodules or ant build scripts could
be used just as well. If the base idea sounds ok, I could tinker around and
show a prototype of how it could look.


             reply	other threads:[~2020-11-22  0:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22  0:23 Arvydas Silanskas [this message]
2020-11-22  1:29 ` Per Bothner
2020-11-22 23:22   ` Arvydas Silanskas

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

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