Connor Lane Smith <c...@lubutu.com> once said: > So I think the necessary next step would be to have a strongly typed > shell. To pretty-print you'd need to add a polymorphic "à la carte" > (multiple dispatch) pretty-printing function for the given data type. > The type inference would be done per command, so cat(1) would be of a > type such that if you were to try catting an image (directly) to wc(1) > it would fail, because the types (Image, String) would not match. You > could also have awesome higher-order functions, so 'map' would remove > the need for find(1), etc.
Then someone will ask for sub-typing and someone else will want ADTs and we'll wake up one day and have to learn category theory just to use a shell. :) A while ago I thought about doing something similar in a more general way. Say we modified the Plan 9 pipe(2) system call to check the current process's namespace for /dev/pipe instead of using the hard- coded pipe(3) device. This would allow us to build custom type-safe pipes as user-space filesystems. You could then do something like: % jsonpipefs -m /mnt/json % ls /mnt/json data data1 % bind /mnt/json /dev/pipe % produce | consume # these commands expect a serialized JSON stream The beauty of this is that the stream typing logic is separated from individual programs and, of course, the shell. Cheers, Anthony
