[Gnu-arch-users] new language, arch, furth, etc.

[Tom Lord]

I worked over the weekend on summarizing a complex idea in a single
concise post that would reveal all the subtle goodness of what I am
about to propose.  I failed at that.  Here instead is the first of a
series of short posts that summarize what I'm proposing, narrating it
in terms of designing an otherwise fairly minor feature (version
variables):




* version variables

  We have a rough idea, expressed here

    http://lists.gnu.org/archive/html/gnu-arch-users/2004-05/msg00890.html

  for "variables" that can be set "per arch version".  For example,
  you could set a version variable named "upstream" in one of your
  branches.  Later, you could say "merge from whatever version is
  bound to the version-variable `upstream'".

  The rough idea is that log messages can contain extra headers.
  Those headers define the values of version variables.   You might
  commit with a header like:

        set-in-version: (upstream "address@hidden/tla--devo--1.3")


* the need for a language

  So, there you have it: the simple idea of version variables suddenly
  gives rise for the need for a tiny, probably not turing complete,
  programming langauge.   That string:

        (upstream "address@hidden/tla--devo--1.3")

  suggesting an "assignment" of the value:

        "address@hidden/tla--devo--1.3"

  to the variable 

        upstream

  points at the need for a tiny (limited even) programming language.
  For example: what _types_ of values can be assigned to variables?
  and, what does assigment mean (e.g., what if two statements assign
  to the same variable).


* the need for language coherence

  Arch has a _bunch_ of tiny little langauges like that.   There 
  will be one for version variables, sure, but there's already one
  for =tagging-method others for various files under ~/.arch-params
  and some more for the =meta-info directory of an archive.   Beyond
  those, package-framework (what arch uses for configure/bulid) has 
  a bunch of tiny languages.

  I made all of those languages.  You might expect, therefore, that
  they'd all be coherent, right?  Wrong:  different comment syntaxes
  (and some with no support for comments at all), different
  data-types, different semantics for "assignment", etc.   It's a 
  growing mess unless we get out in front of it and reign it in.


Meanwhile, people are saying things to me like "I need to see some
examples of what furth is for before I believe it is a good idea...."

Ok, well, the next few posts from me are about this problem area --
about language design for tiny little configuration languages.   I set
out to solve that but, along the way, remembered, recognized and
reaslized various earlier thoughts I had about language design.   A
neat little family of languages results and the next serveral posts
are about those and their design.

-t