From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 19 Jan 2010 22:33:10 +0000 From: Andy Spencer To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20100119223310.GB22431@c.hsd1.tn.comcast.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_c-22711-1263940415-0001-2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] dataflow programming from shell interpreter Topicbox-Message-UUID: c0b44314-ead5-11e9-9d60-3106f5b1d025 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_c-22711-1263940415-0001-2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Is this possible for UNIX philosophy to develop further? Let's say, > XML-coded trees or graphs instead of one-line strings in stdin/ > stdout.Or LISP S-expressions. New set of utilities for filtering such > streams, grep for XML trees, etc. Building environment for dataflow > programming from shell interpreter. > Any interesting papers exist on this topic? I worked on an undergraduate thesis last year about dataflow programming. The syntax for our language was similar to UNIX shells, but it was intended to be compiled language. For more complex datatypes, I don't think the serialization format matters very much. You could store the data in XML, S-expressions, YAML, etc. As long as you have a program/function to read each of these formats into a nested data structure you can use the same set of utilities to process any of them. For parallelism, you'll need to be able to begin outputting the data structure while the original data it is still being read in. With complex data, I'm not sure if it would be better to use a common format through a character pipe, or to use some other form of IPC where the nesting is maintained during transmission. For reference, here's a copy of my thesis: http://andy753421.ath.cx/linked/curin.pdf --=_c-22711-1263940415-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAktWMz4ACgkQz1OYJ/s1XTCMqwCggjaN1PwreldTLa4cX/sZIWSu 1nsAmwVS6sn3/xgA0tSWopjtZVpJ4ehP =Ij5+ -----END PGP SIGNATURE----- --=_c-22711-1263940415-0001-2--