From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 06 Apr 2009 12:02:21 EDT." References: From: Bakul Shah Date: Mon, 6 Apr 2009 09:50:10 -0700 Message-Id: <20090406165010.9745B5B23@mail.bitblocks.com> Subject: Re: [9fans] typed sh (was: what features would you like in a shell?) Topicbox-Message-UUID: d375c2bc-ead4-11e9-9d60-3106f5b1d025 On Mon, 06 Apr 2009 12:02:21 EDT erik quanstrom wrote: > > If program A outputs numbers in big-endian order and B > > expects input in little-endian order, A|B won't do the "right > > thing". > > non-marshaled data considered harmful. film at 11. ☺ In effect you are imposing a constraint (a type discipline). Even if the programs themselves check such constraints, the compatibility idea exists. > what i said was not that A|B "makes sense" for all A and B > and for any data but rather that using text streams makes > A|B possible for any A and any B and any input. the output > might not be useful, but that is a problem on a completely > different semantic level, one that computers are usually no good at. > alsi, i don't think that "type compatability" is sufficient > to insure that the output "makes sense". what if A produces > big-endian times in ms while B expects big-endian times in µs. In effect you are saying that text streams allow nonsensical pipelines as well as sensible ones and anything other than text streams would imply giving up freedom to create sensible pipelines as yet unthought of. No disagreement there but see below. > > Even for programs like wc have a concept of a > > 'character' and if the prev prog. produces something else you > > will be counting something meaningless. > > that's why plan 9 uses a single character set. > > but forcing compability seems worse. where are these decisions > centralized? how do you change decisions? can you override > these decisions (cast)? how does the output of, say, awk get > typed? I am not suggesting forcing anything; I am suggesting experimenting with s-expr streams (in the context of "typed sh" idea). I don't know if that buys you anything more or if you give up any essential freedom. My guess is you'd build something more scalable, more composable but I wouldn't really know until it is tried. I imagine s-expr-{grep,awk} would look quite different from {grep,awk}. May be you'd end up with something like a Lisp machine.