[<<][meta][>>][..]
Sun Aug 23 13:32:01 CEST 2009

Progress in ideas: how to sell Lisp anyway.

Context: You can't sell Lisp, but you can hide it!
(Note: `lisp' here means also `typed functional language')

I like to play with these things.  Staapl is my current state of
affairs: using a dtyped language (scheme) with a powerful macro &
module system to implement a macro-based untyped Forth dialect.  This
I intend to extend with some static analysis following current
approach to gradual typing in the Scheme literature.  A work in
progress..

So, how to _not_ do that, but get something out there:

* Syntax: I think I can sell a DSL as an x -> C compilers though, as
  long as x is either XML or looks like C.  Syntax is totally
  unimportant for getting the job done, but _essential_ to get
  something sold.

* DSL semantics is something ``you don't talk about''.  It's part of
  the just-make-it-work part that is to be sold as a product: it
  _really_ needs to be _good_ but its goodness should be apparent from
  intuiton.  If you have to explain semantics, you fail.  There needs
  to be a gradual build-up from well-known semantics (i.e. C or Java)
  and all the rest needs to sneak in under the radar.

* Hide a dynamic language core as an ``embedded debugger''.  it's
  essential to have a fully dynamic, introspective language at the
  core of the application.  This doesn't need to be visible outside of
  the debugger though. (See libprim: Scheme and PF).

* Hide as much as possible in the form of ``a library performing
  magic.''  In this case it doesn't matter how it's written, as long
  as the API is clear and simple.  I'd call this: ``write leaf objects
  / components in a typed DSL''.

* During development, move stuff from the dynamic to the static part
  once you understand them.  This makes maintenance easier.
  Translating from a dtyped to a styped implementation usually forces
  you to be more formal, while it makes the code extremely brittle to
  changes.


When I ship a C code generator to a client, assuming they are mostly
interested in the product, and don't intend to modify the compiler
intensively, but nontheless want to have some chance to understand and
slightly modify the codee.  What language should I use?

I'm getting more worried about lisp/scheme.  They are powerful tools
but require a paradigm shift.  Especially macros.  And really, nobody
likes parenthesis.  So I'm thinking, for straightforward recursive
data structure transformation, Ocaml might be a better match..  It's
relatively easy to learn, and the type systems makes it hard to make
changes that work without at least makinga bit of sense..

So, let's focus on the following workflow: use Ocaml programs to
translate XML data structures into C programs.



[Reply][About]
[<<][meta][>>][..]