🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.transputer
Article #2826

Re: STRAND88

#2826
From: Nick Rothwell
Date: Mon, 19 Feb 1990 12:43
59 lines
2930 bytes
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...
Technical Details
Message-ID: <2350@castle.ed.ac.uk>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!lfcs!nick
References: <9002130010.AA02911@>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!lfcs!nick
From: nick@lfcs.ed.ac.uk (Nick Rothwell)
Newsgroups: comp.sys.transputer
Subject: Re: STRAND88
Message-ID: <2350@castle.ed.ac.uk>
Date: 19 Feb 90 12:43:05 GMT
References: <9002130010.AA02911@>
Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell)
Organization: Waldorf Micro-Wave Tracking/Sighting/Authentication Subcommittee
Lines: 59
In-reply-to: dan%@@uunet.UU.NET (Daniel Cohen)