Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!dan%@@uunet.UU.NET From: dan%@@uunet.UU.NET (Daniel Cohen) Newsgroups: comp.sys.transputer Subject: Re: STRAND88 Message-ID: <9002130010.AA02911@> Date: 13 Feb 90 00:10:52 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 85 Nick Rothwell writes: Well, I use the term dataflow language to refer to those simple-minded antiquated languages which only have integers and single-assignment. I think any "real" modern language has a user-extensible type system and a fair degree of polymorphism such that you can do "dataflow" on objects of any type; then, you start getting into problems with structured objects going out of scope, and garbage collection and so on. STRAND88 does have a user-extensible type system, and is polymorphic, as discussed below: > What sort of type system does the language have? Polymorphic? Dynamic? > >Polymorphic Good. Is there a formal type semantics? You lost me here! Are you asking for a formal semantics for Strand ( denotational semantics or VDM etc. ) ? > Does it address the problems associated with programming in the > large (modules, interfaces, abstraction)? - or is that outside its > scope? > >There is a module system which is smart enough >to load modules automatically when they are required. >... >We liked Strand because it seemed like a good language >to build up on - object-oriented systems; rule-based >systems etc. but most of this work is still at a conceptual >level ( except objects ). There's also been a lot of work >done on programming methodologies which should eventually >result in some dataflow and/or object-oriented CASE tools. That's not exactly what I meant; for large systems you want to be able to construct interface specifications containing abstract types, and have a way of matching these to actual implementations. For a proper object-oriented system, you need (multiple) inheritance, and from here the type semantics starts to get a little hairy. The problem with Prolog and the like is the lack of scoping of declarations, which is a serious drawback IMHO. Hmmm. I think you do need a copy of the Foster and Taylor book to answer your questions 'cos I'm still not sure I understand them! As for inheritance; I should distinguish between raw Strand ( at which level Strand processes can be construed as proto-objects ) and something built in Strand ( StOOPS ?!? ). In the former case, there is no inheritance: objects can feed any other arbitrary object with their leftovers. In the latter case, any inheritance or delegation scheme you care to think up can probably be coded in Strand very easily since the language is designed for manipulating streams. For some reading on the low-level interpretation of Strand processes as objects, try "Objects - A Fresh Look" by Xerox PARC's Ken Kahn ( ECOOP 89 proceedings ); you might also like to read: "Money as a Concurrent Logic Program" by Ken Kahn and William Kornfeld ( NACLP 89 proceedings ). On a more general note: how much take-up do you expect there to be for a new language in a world dominated by Fortrash, C, and to some extent Occam? Just curious how much of a commercial risk this is, since I'm mostly involved in the academic side of language research. That's partly up to people like you! The language model is interesting enough to get lots of academics involved, but it's not just interesting - there are significant benefits to a programmer in using Strand. Fortran and C will, of course, continue to have the lion's share of scientific and general-purpose computing; but they are not well suited to parallel processing - Strand is. Research at Argonne National Laboratory makes it clear that bilingual ( or multilingual ) programming will be of great importance in the application of parallel systems. Daniel Cohen Strand Software Technologies Inc. 15220 NW Greenbrier Parkway, Suite 350 Beaverton, OR 97006, USA Tel: +1 (503) 690 9830 e-mail: dan%ssti@uunet.uu.net or uunet!ssti!dan