From Keith.Bierman@eng.sun.com Mon Feb 27 01:03:06 1995 Received: from Sun.COM (koriel.Sun.COM) by dkuug.dk with SMTP id AA08832 (5.65c8/IDA-1.4.4j for ); Mon, 27 Feb 1995 18:04:18 +0100 Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03394; Mon, 27 Feb 95 09:03:22 PST Received: from chiba.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) id AA28060; Mon, 27 Feb 1995 09:03:18 -0800 Received: from localhost by chiba.Eng.Sun.COM (4.1/SMI-4.1) id AA02011; Mon, 27 Feb 95 09:03:07 PST Message-Id: <9502271703.AA02011@chiba.Eng.Sun.COM> To: Walt Brainerd Subject: Re: (SC22WG5.734) F9? In-Reply-To: Your message of "Sun, 26 Feb 95 09:22:08 MST." <199502261619.AA25553@dkuug.dk> Cc: SC22WG5@dkuug.dk Date: Mon, 27 Feb 95 09:03:06 PST From: Keith.Bierman@eng.sun.com X-Charset: ASCII X-Char-Esc: 29 > Greenfield said he thought things like inter- > language issues were more important than Back in '77 one might have attempted something akin to the CLID/CLIP stuff, because so many lanaguages had a chance of being really vital. MSDOS, Windows, Unix (all flavors), and most of the embedded real time OSes, all have C interfaces (some also have C++, but for the forseeable future, C is going to have a way to bind too). So restricting the work to C makes it far more feasible. If *every* datatype in C has a counterpart in f9x, we define a mapping and etc, the work of interfacing to any system facility (and folks want direct access to network code and other non-window services) will be something that any user, or user organization can undertake. Trying to accomodate arbitrary languages is arbitrarily hard, and slow.