wm@CSE.OGC.EDU (Wm Leler) (10/16/89)
I have to throw in my two cents worth about Strand. The Stand Software Technologies people came out for a visit last Friday and gave us a demonstration. I must say that I was impressed. Declarative languages like Strand have been around for a while, but despite their benefits haven't become popular yet. I believe that their advantages in terms of parallel execution might be just the thing that gives them a break. In addition to parallel logic programming languages like Strand, there has been quite a bit of work with (purely) functional languages (e.g., Paul Hudak's), and even more esoteric languages, like constraint languages (consider that a plug for my book!). I don't consider Linda and Strand to be competitors, any more than Prolog and C are competitors. Each language has its purposes, advantages and disadvantages. In addition, Strand is a language, while Linda is a set of communications primitives that you add to an existing language. We have added (a version of) Linda to C++, C, FORTRAN, and (even) PostScript, and it is entirely reasonable to add a binding to Strand (although you would lose some of the declarative reading of Strand). You could also write an implementation of Strand that uses Linda (in particular, Strand could benefit from some of the work we have done on using an oracle for process placement). Currently (I believe this can change in the future) Strand88 is an interpreted language, although you can call routines that are compiled from other languages (including C, FORTRAN, and -- soon -- COBOL!). I like Strand's ability to combine different languages into a single program. Currently this is done statically (you have to relink Strand with the modules written in other languages) but I think that you could use Linda (at last Kernel Linda) to do this "linking" dynamically. Linda and Strand would work well together. Just to generate some discussion about Strand (and if you haven't read the book yet, get it!) I throw out the following questions. In Strand, even though a program has a declarative reading, "or" parallelism is handled sequentially. This means that the following program: foo(X) :- X>0 | do_something. foo(X) :- otherwise | do_something_else. will execute the same as this program, although they have different readings. foo(X) :- X>0 | do_something. foo(X) :- true | do_something_else. I can justify this by saying that the second program is wrong, so we don't care if it executes the same as a correct program. But my question is, is there a program that will not execute correctly, or must be written differently, because the different "or" clauses are executed in order? My only other comment is that I wish that streams in Strand were a little more explicit, rather than doing the standard hack (?) of a procedure calling itself at the last moment. In particular, in using such a routine from the keyboard you have to keep inventing new variable names for the stream. Wm Leler Cogent Research, Inc.
dan%@@uunet.UU.NET (Daniel Cohen) (02/03/90)
uunet!wuibc3!gerald writes:
To: dan@ssti
Subject: What is STRAND ?
I have been seeing the name STRAND88 going by for some time
on the Transputer news group, but I have never seen an
explanation of what it is.
Could you give me a short description of STRAND...
Sounds like we're not getting our marketing done!
Strand is a parallel programming language with research roots
in the PARLOG group at Imperial College, the Concurrent Prolog group
at the Weitzman Institute, and the ICOT project. Although its' origins
are in logic programming, it's a dataflow language as much as an LP
language ( although some people say it's an OOP language! )
STRAND88 is an implementation of the Strand language produced by
Strand Software Technologies in conjunction with Ian Foster and
Steve Taylor. It's available on a number of systems - parallel
and sequential - including transputers ( mostly plug-in boards ).
Strand is good for parallel programming because of its' computational
model; a program runs by the repeated reduction of processes - when
one process is reduced others may be spawned - until the processes
are defined by built-in kernels. Processes communicate via shared
variables, which we implement using message-passing when
the processes run on different processors. The point is that the code
to achieve inter-process communications is the same, regardless of
whether the processes are running on the same processor or on
different processors ( in fact, the programmer does nothing;
both processes refer to the variable and the Strand system handles
the communication ). That makes it good for prototyping since the
process-processor allocation is not set in stone and can be changed
for experimentation.
There's a foreign function interface ( C and Fortran at the moment )
so you don't have to do everything in Strand - some use Strand just
for the top level: starting processes and handling the communication
between them, while the 'real work' is done by conventional code.
If anyone wants more information, feel free to contact me ( if you're
in N. America ) or the UK office if you're elsewhere. Ignore the
return address in the header - I have to fix sendmail.cf!
Otherwise, we'll be at NATUG 3 in Santa Clara in April.
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
UK office:
Strand Software Technologies
Greycaine Road
Watford, Herts. WD2 4JP
Tel: +44 923 247707
e-mail: STRAND88@ail.co.uknick@lfcs.ed.ac.uk (Nick Rothwell) (02/05/90)
In article <9002030300.AA00916@>, dan% (Daniel Cohen) writes: >Strand is a parallel programming language with research roots >in the PARLOG group at Imperial College, the Concurrent Prolog group >at the Weitzman Institute, and the ICOT project. Although its' origins >are in logic programming, it's a dataflow language as much as an LP >language ( although some people say it's an OOP language! ) Sounds just like Shapiro's Concurrent Prolog to me. Concurrent Prolog is quite nice (as long as you don't want to backtrack, since it doesn't), but it has some flaws, such as the fact that the guards are supposed to execute (and unify) without affecting the rest of the system, and I could never figure out a way of ensuring this without a huge overhead (Shapiro's papers seem to punt on this one); so, my compiler didn't bother. Does Strand deal with this? If Strand is aimed at a local-memory model of computation, how is store management handled? (not to mention chains of unification and all this nasty stuff.) What sort of type system does the language have? Polymorphic? Dynamic? Does it address the problems associated with programming in the large (modules, interfaces, abstraction)? - or is that outside its scope? >Strand is good for parallel programming because of its' computational >model; a program runs by the repeated reduction of processes - when >one process is reduced others may be spawned - until the processes >are defined by built-in kernels. This sounds like parallel combinator reduction, which is fine as an intermediate form but I don't know if I'd like to program that way. Could you post some examples of Strand programs? (Do you have a mailing list, electronic or otherwise?) It's interesting to hear what it can do, but that's not much use without some actual examples of code to illustrate some of the above points. >Daniel Cohen Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...als das Kind, Kind war...
dan%@@uunet.UU.NET (Daniel Cohen) (02/06/90)
Nick Rothwell writes: Sounds just like Shapiro's Concurrent Prolog to me. Concurrent Prolog is quite nice (as long as you don't want to backtrack, since it doesn't), but it has some flaws, such as the fact that the guards are supposed to execute (and unify) without affecting the rest of the system, and I could never figure out a way of ensuring this without a huge overhead (Shapiro's papers seem to punt on this one); so, my compiler didn't bother. Does Strand deal with this? Yup, Strand guard tests are NOT general-purpose Strand procedures; they are all kernels ( ie. not written in Strand ) which cannot assign variables. We believe this is essential if the language is to run efficiently. If Strand is aimed at a local-memory model of computation, how is store management handled? (not to mention chains of unification and all this nasty stuff.) Another surprise for Prolog fans ( like me ) - no unification! Strand matching is one-way only, forcing the programmer to think more about inputs and outputs. Incomplete structures can still be used ( as when one process sends an incomplete message to another, for the latter to fill in the result ), just it won't all be done in the head-matching phase ( same restriction as for the guard, really - no assigning variables until a clause has been selected ). This is why Strand 'feels' like a dataflow language, rather than a logic-programming language. What sort of type system does the language have? Polymorphic? Dynamic? Polymorphic 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 included fast foreign function interfaces ( currently C and Fortran ) at the abstract machine level ( ie. programmers can write their own guard and body kernels in, say, C ) because many users want to use Strand as a 'harness' for running conventional code in parallel; we hope to extend the range of interfaces in the future ( eg. we already have some material for X-Windows output ). I'm not quite sure what you mean by 'abstraction' here. 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. >Strand is good for parallel programming because of its' computational >model; a program runs by the repeated reduction of processes - when >one process is reduced others may be spawned - until the processes >are defined by built-in kernels. This sounds like parallel combinator reduction, which is fine as an intermediate form but I don't know if I'd like to program that way. We can supply STRAND88 on 'test drive' on Sun's, if you'd like to play around with it ( unfortunately we have to charge for the media and materials ). But why don't you get hold of the book by Foster and Taylor: "Strand: New Concepts in Parallel Programming" ( Prentice-Hall ISBN 0-13-850-587-X; contact us if you can't find it ). That should give you a feeling for what it's like to program in Strand. Someone else asked for some references to Strand; I'll collect a list and post them next week. Could you post some examples of Strand programs? (Do you have a mailing list, electronic or otherwise?) It's interesting to hear what it can do, but that's not much use without some actual examples of code to illustrate some of the above points. Will do, when I have time! Or else send me a message, and we'll send you some literature. 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
nick@lfcs.ed.ac.uk (Nick Rothwell) (02/07/90)
In article <9002060301.AA01527@>, dan% (Daniel Cohen) writes: >Me: > If Strand is aimed at a local-memory model of computation, how is > store management handled? (not to mention chains of unification and > all this nasty stuff.) > >Another surprise for Prolog fans ( like me ) - no unification! >Strand matching is one-way only, forcing the programmer to think >more about inputs and outputs. Incomplete structures can still >be used ( as when one process sends an incomplete message to >another, for the latter to fill in the result ), just it won't >all be done in the head-matching phase ( same restriction as for >the guard, really - no assigning variables until a clause has >been selected ). Fair enough. So presumably Strand deals with passing such incomplete messages from (if necessary) one processor to another, such that the "holes" serve as semaphores for the message generator to fill in. >This is why Strand 'feels' like a dataflow >language, rather than a logic-programming language. 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. > What sort of type system does the language have? Polymorphic? Dynamic? > >Polymorphic Good. Is there a formal type semantics? > 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. >But why don't you >get hold of the book by Foster and Taylor: >"Strand: New Concepts in Parallel Programming" >( Prentice-Hall ISBN 0-13-850-587-X; contact us if you >can't find it ). That should give you a feeling for what >it's like to program in Strand. Ok, I'll chase that up. 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. >Daniel Cohen Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...als das Kind, Kind war...
dan%@@uunet.UU.NET (Daniel Cohen) (02/13/90)
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
nick@lfcs.ed.ac.uk (Nick Rothwell) (02/19/90)
In article <9002130010.AA02911@>, dan% (Daniel Cohen) writes: >STRAND88 does have a user-extensible type system, and >is polymorphic, as discussed below: No, not by my definitions (and based on a recent Strand-88 presentation I went to). Strand-88 has dynamic point-of-call typechecking, and no type system. >You lost me here! Are you asking for a formal semantics >for Strand ( denotational semantics or VDM etc. ) ? I wondered if there was any kind of semantics describing the type system, but since Strand isn't typed, this is mute. I was also wondering if there was any kind of formal definition of the language; how do you define the meaning of things like Foo :- tt_input(Direction), my_computation()@Direction for instance? (syntax is approximate.) 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. I was thinking of inheritance in the Eiffel sense, with static analysis of class matching and consistency. I wouldn't like to have to design an inheritance heirarchy without the help of a reliable, sound, static type system for it. >That's partly up to people like you! The language model is >interesting enough to get lots of academics involved, Interesting, yes, but nothing new; I was hacking together a Concurrent Prolog compiler back in '83, and Strand isn't much more than Concurrent Prolog. However, if it does everything that is claimed (including process and data migration, parallel garbage collection, and so on), then I'm impressed (especially if you can get decent performance out of it, given the sort of runtime overheads that interpreting a Strand program entail). But, I view the lack of a type system and decent static modularisation facilities as rather a drawback. >but 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 Fortran and C aren't well suited to any kind of processing any in this day and age. But that's just my opinion. >Daniel Cohen Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...als das Kind, Kind war...