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

[Phil Frost]

Every time someone suggests designing a new language, somewhere a fairy
dies. I think it's a law of nature that no matter how simple the needs
may seem now, in the end all languages evolve to be turing complete.
Since nobody likes writing in brain****, this means they also get pretty
complex.

Which begs the question, why not consider using an existing language
now? I suggest Python because it's easilly embedded and clean. Someone
might suggest lua, but I don't like it for its syntax. In any case, if a
decent language isn't picked *now*, I fear tla will "evolve" to have
configuration files with a syntax like Exim. An nobody wants that.


On Mon, Jul 19, 2004 at 08:40:41PM -0700, Tom Lord wrote:
> 
> 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