9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mash
Date: Fri,  3 Nov 2000 17:25:54 +0000	[thread overview]
Message-ID: <20001103162420.6684B199E9@mail> (raw)

leo caves wrote;
> the lack of adoption sends a confusing message.
> the fact that there is another command shell for inferno without
> these features seeemingly relegates the "make" functionality
> to another special purpose language.

i liked mash, in principle, but i thought its syntax was unnecessarily
complex, leaving behind some of the simplifications that rc had given
us, and adding expressions, for instance.  limbo made it very easy to
provide loadable shell modules, but i thought that it should be
possible to do more with less.

i had already written most of an inferno shell before mash, so i dusted
it off, borrowed most of the good ideas from mash, and that became the
inferno shell.  it's comparable in size to mash but simpler and more
versatile, i think.  the syntax is very small, but still substantially
similar to rc's.

it should be quite possible to write a "make"-style dependency module
for it without changing the syntax at all.

the key being that it allows the passing around of fragments of
shell-script as values, so it would be perfectly possible to write a
built-in shell module that defined a command "dep" (dependency) that
might look something like:
	dep x.dis : x.b {
		limbo -g x.b
	}
or:
	dep %.dis : %.b {
		limbo -g $stem.b
	}
and a "mk" command to do the customary make-style dependency
evaluation, executing recipes as necessary.

in this scheme, you do lose the advantages of having a special syntax
for the make features (e.g. distinguishing between quoted and unquoted
wildcard chars), but the shell syntax isn't cluttered with stuff that's
essentially only good for one application, and only in the way
otherwise. swings and roundabouts.

i don't know how long mash will stay in the inferno distribution, once
i've plundered its "make" code and converted it to sh...  but then i'm
completely biased, and probably wrongheaded about all of this as a
result!

  cheers,
    rog.



             reply	other threads:[~2000-11-03 17:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-03 17:25 rog [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-02 13:20 rob pike
2000-11-02 15:54 ` Rick Hohensee
2000-11-03  9:27   ` Leo Caves
2000-07-18  7:42 [9fans] Mash forsyth
2000-07-18  8:18 ` Lucio De Re
2000-07-18  8:24   ` Lucio De Re
2000-07-17  2:01 pip
2000-07-16 22:21 ` Boyd Roberts
2000-07-17  0:57 pip
2000-07-16 21:49 ` Boyd Roberts
2000-07-16 22:20 brucee
2000-07-16 17:50 brucee
2000-07-17  9:12 ` Chris Locke
2000-07-18  6:27   ` Lucio De Re

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20001103162420.6684B199E9@mail \
    --to=rog@vitanuova.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 NNTP newsgroup(s).