> > > > > The feature I want is the ability to pass not just character > > > > > values in environment or pipes but arbitrary Scheme objects. > > > > > But that requires changes at the OS level (or mapping them > > > > > to/from strings, which is a waste if both sides can handle > > > > > structured objects). > > > > > > > > !? the ability to pass typed records around is an idea that was > > > > tarred, feathered, drawn and quartered by unix. files, and therefore > > > > streams, have no type. they are byte streams. > > > > > > I was not talking about "records" but s-expressions. "json" > > > is kind of sort of the same thing. Without a generally useful > > > and simple such mechanism, people end up devising their own. > > > The 9p format for instance. And go has typed channels. > > > > it sounds like you're saying 9p isn't useful. .... i must be reading > > your post incorrectly. > > 9p is quite useful. But the same semantics could've been > implemented using a more universal but compact structured > format such as s-expr. It is not the only choice but to me it > seems to strike a reasonable balance (compared to bloaty XML > at one extreme, tightly packed binary structures at another, > and byte streams with printf/parse encode/decode at the third > extreme).
i don't see the problem. 9p is not in any way special to the kernel. only devmnt knows about it, and it is only used to mount file servers. in theory, one could substitue something else. it wouldn't quite be plan 9, and it wouldn't be interoperable, but there's no reason it couldn't be done. authentication speaks special protocols. venti speaks a special protocol. so i don't see why kernel support would even be helpful in implementing your s-expression protocol. and there's no reason a 9p over s-expression device can't be implemented. imho, the reason for constraining 9p to exactly the operations needed is to make it easy to prove the protocol correct. - erik
