Re: Solid modeling in Guile

["Thompson, David" <dthompson2@worcester.edu>]

Hello Matt,

On Thu, Aug 18, 2016 at 5:44 PM, Matthew Keeter <matt.j.keeter@gmail.com> wrote:
> Hi Guile-folks,
>
> I wrote a computer-aided design (CAD) tool that you may find interesting.
>
> It’s a solid modeling tool that uses Guile scripts to define objects (and
> constructive solid geometry + functional representations under the hood).
>
> Project page:  http://www.mattkeeter.com/projects/ao/
> Source:  https://github.com/mkeeter/ao

This is a really awesome project.  Just recently I was lamenting that
I didn't know how to use any CAD tools and was wishing that there was
one that used Guile.  Good timing!  The section of the website that
explains the advantage over software like OpenSCAD really resonated
with me.  It seems like a successful application of the Emacs design
philosophy to computer aided design.

Unfortunately, I haven't been able to build Ao because I can't get
CMake to find my glfw3.pc pkgconfig file.  PKG_CONFIG_PATH was set
appropriately as I use GuixSD which has no notion of the global /usr
directory.  Do you know how to explicitly tell the build system about
glfw3.pc?

> I’d love feedback – Scheme is relatively new to me, so I’m sure there are
> more elegant ways to accomplish a lot of what the code implements.

I think so far you've done a great job, so consider the following
criticism to be of the "it would be really cool if..." variety.  I
watched the video of Ao in action, and while auto-reload of script
files is cool, it's no replacement for a REPL server.  So, in addition
to having that REPL attached to your terminal's STDIN/STDOUT, it's
possible to make a REPL server[0] in guile that listens on a port or
uses a UNIX domain socket.  This unlocks great hacking power for Emacs
users who can use Geiser[1] to connect to the REPL and write/eval code
directly from their Scheme buffers.  This kind of interaction is much
preferred over having to save and reload entire script files as it
allows for more incremental computation and a faster feedback loop.

Additionally, embedding Guile in a C/C++ application has become a
somewhat discouraged practice.  The recommended architecture these
days is to write the entire program in Guile and use the foreign
function interface to access C libraries (GLFW and friends, in your
case) when needed.  This would make Ao a Guile library in addition to
an executable, and having everything written in Guile means that users
can easily hack on any part of Ao from the comfort of their REPL
without having to edit C code and recompile.  There's a good article
written by Python programmers[2] that explains the advantages of
extending over embedding.  I don't know how feasible this is to do in
the case of Ao, but I've had good luck in the past transforming
software from an embedded model to an extended one.  The more code
that is written in Scheme the better!

Anyway, great work!  I hope I can get this to build at some point, and
if you ever make an official release please let us know so that
someone can package it for GNU Guix. :)

- Dave

[0] https://www.gnu.org/software/guile/manual/html_node/REPL-Servers.html
[1] http://geiser.nongnu.org/
[2] https://twistedmatrix.com/users/glyph/rant/extendit.html