budd@mist.CS.ORST.EDU (Tim Budd) (04/28/89)
I'm looking for examples (if any) of any compiled, possibly strongly typed, languages in which functions/procedures are first class values (i.e., can be stored in variables, can be sent as arguments to other functions, can be returned as the result of a function, and so on). I'm currently designing and implementing such a thing, and want to know what previous work has been done. --tim budd budd@cs.orst.edu
budd@mist.CS.ORST.EDU (Tim Budd) (04/28/89)
oops. After pondering for ten more minuits after I posted my earlier note about langauges with first class functions I realized my question was either unclear or trivially obvious (take your pick). I realized that being able to assign functions to variables, return them from functions, and so on isn't really the issue. You can do all that in C, but that doesn't make functional programming in C similar to functional programming in, say, scheme or ISETL. Try writing a curry-ing function in C, for example, and you can see what I mean. The reason why C functions aren't as useful (in this case) is that C functions can't be nested, and thus don't have to remember their state. Nested functions bring on upward and downward funarg problems, but that isn't the same thing as being able to assign a function to a variable. so my question boils down to asking for compiled languages that have nested functions and first class functions, and thus have to deal with funarg (functional argument) problems; and how they do it. And actually now that I think more about it SL5 springs to mind. Any others? --(a now red-faced) tim budd; budd@cs.orst.edu
choo@cs.yale.edu (young-il choo) (05/02/89)
In article <10253@orstcs.CS.ORST.EDU> budd@mist.CS.ORST.EDU (Tim Budd) writes:
TB> so my question boils down to asking for compiled languages that have nested
TB> functions and first class functions, and thus have to deal with funarg
TB> (functional argument) problems; and how they do it. And actually now that
TB> I think more about it SL5 springs to mind. Any others?
TB> --(a now red-faced) tim budd; budd@cs.orst.edu
The one I know about is Algol 68.
-- Young-il Choo
choo-young-il@yale.edu
Yale Computer Science New Haven CT 06520-2158kers@otter.hpl.hp.com (Chris Dollin) (05/03/89)
Young-il Choo says: | TB> so my question boils down to asking for compiled languages | TB> that have nested functions and first class functions, and | TB> thus have to deal with funarg (functional argument) | TB> problems; and how they do it. And actually now that I think | TB> more about it SL5 springs to mind. Any others? --(a now | TB> red-faced) tim budd; budd@cs.orst.edu | | The one I know about is Algol 68. | | -- Young-il Choo | | choo-young-il@yale.edu | Yale Computer Science New Haven CT 06520-2158 Algol68 doesn't quite have first-class functions. You are not allowed to export a function out of the extent of the block that declared it, *especially* if it references locals of the outer block, i.e., the interesting and useful case. Ones that do have proper first-class functions include Scheme, Common Lisp, ML (and any pure functional language worth mentioning), and Pop11. If you're interested, I can describe how Pop11 does its first-class functions; I won't burden the whole Net unless I get overwhelmed by requests. Regards, | "Once I would have been glad to have made your acquaintance Kers. | Now I feel the danger brought about by circumstance."
jack@cs.glasgow.ac.uk (Jack Campin) (05/03/89)
budd@mist.CS.ORST.EDU (Tim Budd) wrote: > I'm looking for examples (if any) of any compiled, possibly strongly typed, > languages in which functions/procedures are first class values (i.e., can be > stored in variables, can be sent as arguments to other functions, can be > returned as the result of a function, and so on). PS-algol does this. I posted a list of tech reports about it to the comp.doc.techreports newsgroup a few months ago. The extra feature it has beyond what you're asking for, and the critically important one, is the ability to make functions persistent - thus a partial application of a procedure can be constructed and later reinvoked at any time *with the environment of its creation*. This gives the full power of a typed module facility, but without the restriction that module bindings have to happen at "link time". It compiles to an abstract machine code for an interpreter. It's strongly typed, sort of (well, stronger than Scheme, anyway; some sort of get-out is needed to handle long-term persistent data with reasonable flexibility - PS-algol treats complex objects as all having the same compile- time type but imposes run-time type checks on accesses to their insides). The one thing you can't do is use procedure closures as keys for associative data structures, though we've done some experiments towards this. Of course ML and Miranda-like languages have "first class" procedures too, but without persistent closures they are limited in what they can do with them. [ I couldn't get this to comp.compilers by following up - does anyone know a good way to reach the moderator from the UK? ] -- Jack Campin * Computing Science Department, Glasgow University, 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND. 041 339 8855 x6045 wk 041 556 1878 ho INTERNET: jack%cs.glasgow.ac.uk@nsfnet-relay.ac.uk USENET: jack@glasgow.uucp JANET: jack@uk.ac.glasgow.cs PLINGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
turner@sdti.SDTI.COM (Prescott K. Turner) (05/05/89)
In article <2400023@otter.hpl.hp.com> kers@otter.hpl.hp.com (Chris Dollin) writes: >Ones that do have proper first-class functions include Scheme, Common >Lisp, ML (and any pure functional language worth mentioning), and Pop11. >If you're interested, I can describe how Pop11 does its first-class >functions; I won't burden the whole Net unless I get overwhelmed by >requests. I'm somewhat familiar with Scheme's "first-class" functions, and like them. But isn't it false advertising to claim first-class functions unless you can compare functions for equality just like other types? This means that the implementation will return "not-equal" if the functions are different, return "equal" if they can be proved equivalent, and otherwise continue searching for a proof or counterexample indefinitely. Are there any languages which support this? -- Prescott K. Turner, Jr. Software Development Technologies, Inc. P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
akwright@watdragon.waterloo.edu (Andrew K. Wright) (05/07/89)
In article <451@sdti.SDTI.COM> turner@sdti.UUCP (0006-Prescott K. Turner, Jr.) writes: >I'm somewhat familiar with Scheme's "first-class" functions, and like them. >But isn't it false advertising to claim first-class functions unless you >can compare functions for equality just like other types? Why? What is so special about the equality operation over any other operation that it should take part in defining "first-class" functions? What about assignment? Multiplication? Addition? Composition? A language has first-class functions if any function can be passed as a parameter or returned as a result. If the language provides an equality operation for functions, or an assignment operation, this is an independent issue. Andrew K. Wright akwright@waterloo.edu CS Dept., University of Waterloo, Ont., Canada.
steveb@cs.utexas.edu (Steve Benz) (05/07/89)
turner@sdti.UUCP (0006-Prescott K. Turner, Jr.) writes: >.. But isn't it false advertising to claim first-class functions unless you >can compare functions for equality just like other types? Then again, you really shouldn't compare floating point numbers for equality either. Can we conclude that floating point numbers aren't first class? Clearly, no. Some operators apply to some data types, and don't apply to other types. Functions are first class objects in Scheme, but they really shouldn't be compared for equality--just the same as real numbers shouldn't be compared for equality. - Steve Benz
laba-4he@e260-4g.berkeley.edu (The Cybermat Rider) (05/08/89)
In article <451@sdti.SDTI.COM> (Prescott K. Turner, Jr.) writes: >I'm somewhat familiar with Scheme's "first-class" functions, and like them. >But isn't it false advertising to claim first-class functions unless you >can compare functions for equality just like other types? This means that >the implementation will return "not-equal" if the functions are different, >return "equal" if they can be proved equivalent, and otherwise continue >searching for a proof or counterexample indefinitely. Are there any >languages which support this? As a matter of fact, Scheme does something akin to this. You can compare functions, but there's a catch: > (equal? (lambda (x) (+ x 1)) (lambda (x) (+ x 1))) () The thing about Scheme is that each lambda expression above creates a separate procedure body, even though the two are similar. The following would work, though, since test1 and test2 point to the same procedure body: > (define test1 (lambda (x) (+ x 1))) test1 > (define test2 test1) test2 > (equal? test1 test2) #t If I understand you correctly, you consider two functions to be "equal" if they are _functionally identical_. Certain languages I know might allow you to write functional equality tests for functions that return numbers, but I daresay that it'll be more than a little difficult to compare functions that return strings, to say nothing of functions that return functions! Take into account the target functions' side-effects, and the problem now takes on gargantuan proportions. >-- >Prescott K. Turner, Jr. >Software Development Technologies, Inc. >P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 >UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com ---------------------------------------------------------------------------- Adrian Ho a.k.a. The Cybermat Rider University of California, Berkeley laba-4he@web.berkeley.edu (WEB Evans, Home of The CS Freakies) Disclaimer: Nobody takes me seriously, so is it really necessary?
smryan@garth.UUCP (s m ryan) (05/08/89)
>Algol68 doesn't quite have first-class functions. You are not allowed to >export a function out of the extent of the block that declared it, >*especially* if it references locals of the outer block, i.e., the >interesting and useful case. I've heard this claim but I don't see where the language (and not some compiler) prohibits begin heap int i; int: i+:=1 end If you can elucidate, please do. -- 16. `The wealth I lose becomes the bane Steven Ryan: ingr!garth!smryan of all who own or seek in vain. 2400 Geng Road, Palo Alto, CA It brings but death to Hreithmar's kin Here have some grub. O they very fine and joy of wealth no man shall win.' baby worms cooked in the holy corn oil.
schow@bnr-public.uucp (Stanley Chow) (05/08/89)
In article <2883@crete.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk (Jack Campin) writes: > >budd@mist.CS.ORST.EDU (Tim Budd) wrote: > >> I'm looking for examples (if any) of any compiled, possibly strongly typed, >> languages in which functions/procedures are first class values (i.e., can be >> stored in variables, can be sent as arguments to other functions, can be >> returned as the result of a function, and so on). > >PS-algol does this. I posted a list of tech reports about it to the >comp.doc.techreports newsgroup a few months ago. The extra feature it has >beyond what you're asking for, and the critically important one, is the >ability to make functions persistent - thus a partial application of a >procedure can be constructed and later reinvoked at any time *with the >environment of its creation*. This gives the full power of a typed module >facility, but without the restriction that module bindings have to happen at >"link time". It compiles to an abstract machine code for an interpreter. >It's strongly typed, sort of (well, stronger than Scheme, anyway; some sort of >get-out is needed to handle long-term persistent data with reasonable >flexibility - PS-algol treats complex objects as all having the same compile- >time type but imposes run-time type checks on accesses to their insides). > We have been using a proprietary language call PROTEL for some big projects. It is a Pascal derrivative type language that has first class functions. We also allow some control over environment but different from PS-algol. Basically, a "process" is composed of "modules", each module has its own mini environment within the process environment. Each module can have a different instance of its own environment in each process. When a procedure variable is created, the module environment is included. You could also construct a procedure variable that runs in the corresponding module environment of a *different* process. The system even keeps track of multiple instances of one module in a proces! PROTEL is pretty strict about types. (After all, it is PRocedure Oriented Type Enforcing Language). The type of a procedure includes the types of all the parameters. As it turns out, passing procedure around can get very dangerous unless the type of a procedure is tracked everywhere. Please e-mail me if you want more details. Some early versions of the l anguage were discribed in SIGPLAN about ten years ago (I think). Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.
jack@cs.glasgow.ac.uk (Jack Campin) (05/08/89)
turner@sdti.UUCP (0006-Prescott K. Turner, Jr.) wrote: > ...isn't it false advertising to claim first-class functions unless you > can compare functions for equality just like other types? This means that > the implementation will return "not-equal" if the functions are different, > return "equal" if they can be proved equivalent, and otherwise continue > searching for a proof or counterexample indefinitely. Are there any > languages which support this? A language that requires an oracle for the Halting Problem is probably not going to be much use to anyone but the Almighty. ML, with good reason, omits this. There is another approach, taken by PS-algol, which is to give procedure equality the semantics of pointer equality on closures. This is not, in practice, very useful. What WOULD be useful would be to go further and have *ordering* on procedures; this would mean they could be used as keys for logarithmically searchable associative data structures. This is a bit harder to implement while keeping orthogonal persistence - all closures that might be compared need to be given persistent pointers - but not ridiculously so. For non-persistent languages like Scheme it should be trivial to add it. Another approach is the constructive type theory one; restrict the functions you can define to provably terminating ones to make orthogonal equality work with the behavioural semantics. This is only good for a small range of problems, though. -- Jack Campin * Computing Science Department, Glasgow University, 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND. 041 339 8855 x6045 wk 041 556 1878 ho INTERNET: jack%cs.glasgow.ac.uk@nsfnet-relay.ac.uk USENET: jack@glasgow.uucp JANET: jack@uk.ac.glasgow.cs PLINGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
norman@a.cs.okstate.edu (Norman Graham) (05/09/89)
From article <451@sdti.SDTI.COM>, by turner@sdti.SDTI.COM (Prescott K. Turner): > But isn't it false advertising to claim first-class functions unless you > can compare functions for equality just like other types? No. It is false advertising to claim first-class functions if (1) you can define a magical function-equality algorithm but (2) your language doesn't allow you to pass functions to a functional abstration of your magical function-equality algorithm. Of course, there are many other things that prevent functions from being first-class, but the requirement that all relations be defined for functions is not among them. In general, values of type 'alpha' (in this case, 'alpha' = 'function') are first-class citizens of a language when that language does not discriminate against them in any way. Reynolds [*] called this the 'Principle of Data Type Completeness' and in particluar it requires that all values (reguardless of type) be (1) passable as parameters, (2) assignable, (3) able to form components of data structures, and (4) able to be returned from functions. Of course, whether any particular function has values of type 'function' in its domain or codomain is still up to the definition of the function and has no bearing on the first-classness of values of type 'function'. [*] J. C. Reynolds, GEDANKEN: a simple typeless language based on the principles of completeness and the reference concept, CACM, vol. 13 (5), 308-319 (1970). -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, rutgers} 219 Mathematical Sciences Building !okstate!norman Stillwater, OK 74078-0599
turner@sdti.SDTI.COM (Prescott K. Turner) (05/10/89)
In article <529@rodan.cs.utexas.edu> steveb@cs.utexas.edu (Steve Benz) writes: > Then again, you really shouldn't compare floating point numbers for equality > either. I've done enough numerical programming to know that this is true 99% of the time. > Can we conclude that floating point numbers aren't first class? I don't buy that. Every language with a successful floating point type has comparison for equality. For several years I helped support a FORTRAN compiler which could handle X = A * B Y = A * B IF (X .NE. Y) ... and execute this statement! Try telling customer after customer that this is their problem. Floating point should be first-class, with equality in the sense these customers wanted. > Clearly, no. Some operators apply to some data types, and don't apply to > other types. Functions are first class objects in Scheme, but they really > shouldn't be compared for equality--just the same as real numbers shouldn't > be compared for equality. Ah, yes. Real numbers of the mathematical kind are much more like Scheme functions than that FORTRAN stuff. But I'm not acquainted with Macsyma, etc. so it sounds to me as if you're just trying to extend what's mostly true for floating point to a quite different beast. ----- Prescott K. Turner, Jr. Software Development Technologies, Inc. P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
turner@sdti.SDTI.COM (Prescott K. Turner) (05/10/89)
In article <13638@watdragon.waterloo.edu> akwright@watdragon.waterloo.edu (Andrew K. Wright) writes: > Why? What is so special about the equality operation over any > other operation that it should take part in defining "first-class" functions? > What about assignment? Multiplication? Addition? Composition? > > A language has first-class functions if any function can be passed > as a parameter or returned as a result. If the language provides > an equality operation for functions, or an assignment operation, > this is an independent issue. I can't argue with this if it's the what most students of computer languages understand by "first-class data type". However, I believe it's possible to state what's "so special" about assignment and equality. Equality of functions is well-defined in the mathematical domain used to specify the semantics of the language at hand. Assignment has a straightforward meaning. In both cases isn't it necessary to add a restriction to the definition of a clean language in order to omit these operators? Am I being naive? ----- Prescott K. Turner, Jr. Software Development Technologies, Inc. P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
turner@sdti.SDTI.COM (Prescott K. Turner) (05/10/89)
In article <24122@agate.BERKELEY.EDU> laba-4he@e260-4g.berkeley.edu (The Cybermat Rider) writes: > If I understand you correctly, you consider two functions to be "equal" if > they are _functionally identical_. Certain languages I know might allow you > to write functional equality tests for functions that return numbers, but I > daresay that it'll be more than a little difficult to compare functions that > return strings, to say nothing of functions that return functions! Take > into account the target functions' side-effects, and the problem now takes on > gargantuan proportions. These are the proportions I had in mind, although I'd be quite satisfied to compare functions that return functions in a language without side-effects. It should be about as hard as a theorem-proving program. -- Prescott K. Turner, Jr. Software Development Technologies, Inc. P.O. Box 366, Sudbury, MA 01776 USA (508) 443-5779 UUCP: ...{harvard,mit-eddie}!sdti!turner Internet: turner@sdti.sdti.com
gudeman@arizona.edu (David Gudeman) (05/11/89)
In article <453@sdti.SDTI.COM> turner@sdti.SDTI.COM (Prescott K. Turner) writes: >... Equality >of functions is well-defined in the mathematical domain used to specify >the semantics of the language at hand. Assignment has a straightforward >meaning. In both cases isn't it necessary to add a restriction to the >definition of a clean language in order to omit these operators? The mathematical equality of two functions is not computable. It can be defined, but there is no effective procedure to implement the definition. Languages that _do_ define equality of functions use some decidable approximation of the real equality predicate, such as "Two functions are equal if they are defined by the same code". In general, this is true of any non-finite value (such as real numbers). Assignment is different. Any language with assignment that does not allow function values to be assigned, does not have first-class functions. -- David Gudeman Department of Computer Science The University of Arizona gudeman@arizona.edu Tucson, AZ 85721 {allegra,cmcl2,ihnp4,noao}!arizona!gudeman
chl@r1.uucp (Charles Lindsey) (05/11/89)
In article <2824@garth.UUCP> smryan@garth.UUCP (s m ryan) writes: >>Algol68 doesn't quite have first-class functions. You are not allowed to >>export a function out of the extent of the block that declared it, >>*especially* if it references locals of the outer block, i.e., the >>interesting and useful case. > >I've heard this claim but I don't see where the language (and not some >compiler) prohibits > > begin > heap int i; > int: i+:=1 > end ALGOL 68 Report 5.4.1.2 The yield of a routine-text T {e.g. INT: i+:=1}, in an environ E, is composed of T and the environ "necessary for" T in E. ALGOL 68 Report 7.2.2.c The environ necessary for T {INT: i+:=1} in this case is that corresponding to the BEGIN ... END, because T contains an identifier {i} that does not identify a defining-identifier contained in T, but does identify one contained in the BEGIN ... END {I paraphrase the Report considerably here}. ALGOL 68 Report 2.1.3.5.c The scope {or extent} of a routine is the scope of its environ. ALGOL 68 Report 3.2.2.a The yield of a serial-clause {the ... inside the BEGIN ... END} in an environ E {some outer block where the result of the BEGIN ... END was needed} ..... . It is required that that yield be not newer in scope than E. The effect of all this, in plain terms, is that you may export a routine out of as many blocks as you like until you reach its "necessary environ", which is one where some identifier used in the routine is declared. There you must stop.
lloyd@bruce.cs.monash.OZ.AU (lloyd allison) (03/06/91)
Does anyone know the full story about why Algol-68 did not allow heap proc, or something like, and thus widen the scope (!) of procs? Not all proc values would have to be on the heap. (In A68 as it stands none are in the heap.) A conservative algorithm would allocate some to the heap that need not be there. If the programmer could write `heap proc' it would be programmer control - might get it wrong of course. In AB37.4.2 July 1974 there is a proposal for partial-parametrization by Charles Lindsey which discusses some of the problems of proc scope. Bekic is mentioned as having a proposal for lifting the scope restriction on procs. B.T.W. did any A68 every implement the partial-p' extension? Lloyd ALLISON Department of Computer Science, UUCP:lloyd@bruce.cs.monash.edu.au Monash University, Clayton, or :uunet!munnari!bruce.cs.monash.edu.au!lloyd VICTORIA 3168, AUSTRALIA Tel :565-5205 FAX: +61 3 565 5146
chl@cs.man.ac.uk (Charles Lindsey) (03/06/91)
In <3787@bruce.cs.monash.OZ.AU> lloyd@bruce.cs.monash.OZ.AU (lloyd allison) writes: >Does anyone know the full story about why Algol-68 >did not allow heap proc, >or something like, and thus widen the scope (!) of procs? You answer your own question fairly well below. >In AB37.4.2 July 1974 there is a proposal for partial-parametrization >by Charles Lindsey which discusses some of the problems of proc scope. >Bekic is mentioned as having a proposal for lifting the >scope restriction on procs. Bekic argued his case strongly during the period leading to the Revised ALGOL 68 Report. The trouble is that there are both run-time and compile-time penalties for this feature, and it is difficult to tell at compile time whether the extra run-time stuff can safely be omitted in the simple cases (thus the Bauer-Samelson criterion - that people who do not use a feature should not pay for it - is violated). I was able to show that partial parametrization provided equivalent functionality to the Bekic proposal, but of course the user then had to explicitly indicate when he needed the extra facilities. In fact, I understand that the ALGOL 68RS system does in fact implement the Bekic proposal, or something close to it. Moreover, all current functional languages do it as a matter of course, but then they have long ago given up the stack model for their implementations. I could send you the relevant working paper on the subject if you really want to see all the gory detail. >B.T.W. did any A68 every implement the partial-p' extension? Not that I know of. >Lloyd ALLISON >Department of Computer Science, UUCP:lloyd@bruce.cs.monash.edu.au >Monash University, Clayton, or :uunet!munnari!bruce.cs.monash.edu.au!lloyd >VICTORIA 3168, AUSTRALIA Tel :565-5205 FAX: +61 3 565 5146
richard@praxis.co.uk (Richard Wendland) (03/09/91)
chl@cs.man.ac.uk (Charles Lindsey) writes: >In fact, I understand that the ALGOL 68RS system does in fact implement the >Bekic proposal, or something close to it. Only one of the ALGOL 68RS implementations, on the RSRE Flex architecture, permits procedures without the normal scope restrictions. I don't know of the Bekic proposal; the implementation on Flex uses normal ALGOL 68 syntax, only the scope rules being relaxed. The Flex architecture, designed around 1978, is geared towards efficient implementation by micro-code, as on a Perq. Heap activation records are always used, and retained by 'shaky pointers' on exit to be reused at the next call of that procedure. The (micro-coded) garbage collector recovers these retained activation records. Procedure values are used as capabilities on Flex, the microcode ensures procedures (and pointers) cannot be fabricated. This provides a secure multi-process environment in a single address space, with an extensible operating system. Flex also has a persistent store, so these first class procedures can even live on disc when you turn the power off! In fact the only real difference between a procedure you can produce and an operating system procedure is that the operating system procedure originated from a boot floppy. It's a shame Flex did not receive more publicity, as it implemented features much discussed later. I talk about it in the present, as I have a Perq running Flex next to me, but it doesn't get switched on too often these days. -- Richard Wendland richard@praxis.co.uk
pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) (03/10/91)
On 8 Mar 91 20:25:16 GMT, richard@praxis.co.uk (Richard Wendland) said:
richard> chl@cs.man.ac.uk (Charles Lindsey) writes:
chl> In fact, I understand that the ALGOL 68RS system does in fact
chl> implement the Bekic proposal, or something close to it.
richard> Only one of the ALGOL 68RS implementations, on the RSRE Flex
richard> architecture, permits procedures without the normal scope
richard> restrictions. I don't know of the Bekic proposal; the
richard> implementation on Flex uses normal ALGOL 68 syntax, only the
richard> scope rules being relaxed.
richard> The Flex architecture, designed around 1978, is geared towards
richard> efficient implementation by micro-code, as on a Perq. [ ... ]
richard> It's a shame Flex did not receive more publicity, as it
richard> implemented features much discussed later.
Flex is a wonderful thing. The Perq too, a bit less. Both have
disappeared without trace. Reasons?
* They are not MSDOS/8086 compatible. :-) :-(.
* They are not BSD/SysV compatible. :-) :-(.
* The Perq's a dog in terms of performance (not "RISC" :->).
* Three Rivers did not get bought out by HP like Apollo.
* Every week one of the few surviving Algol 68 programmers dies.
* RSRE is a very secretive military installation; the Flex was, I
suspect, mainly designed for highly secure military purposes.
At times I suspect that the following two reasons are also relevant:
* The Perq was licensed by ICL. I don't believe in superstition, but ICL
sponsorship used to be something like a kiss of death. :-) :-(.
* The few surviving British computer architects have never been good at
PR, nor have ever given a damn about it (look at Manchester's MUSS for
another example). That's why so few are left. :-( :-).
At times I suspect they are not, as for example also MDL and KeyKOS (in
a sense the USA alter ego of Flex; written in PL/1, running on 370s :->)
are sunk almost without trace.
I renew here my usual call: if the authors of Algol 68C or Algol 68RS
are listening, please get in touch with me. I want to try to persuade
you to release those compilers to the FSF.
If either Algol 68C or Algol 68RS were GPL'ed and posted to comp.sources
:-) I think a lot of people, especially in the USA, would be literally
stunned, and Algol 68 would become very much popular.
The dream of a lifetime...
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uklamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (03/12/91)
In article <PCG.91Mar9211601@aberdb.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: >At times I suspect they are not, as for example also MDL and KeyKOS (in >a sense the USA alter ego of Flex; written in PL/1, running on 370s :->) >are sunk almost without trace. If you like KeyKOS, I have good news for you, because the company is still alive and kicking, and busy improving their product. I have no personal interest in this company, but know someone who works there. (It is a small company, so they don't get a lot of visibility.) They are located somewhere in the Sunnyvale/Santa Clara area - consult your local phone book. For those who are curious, KeyKOS is a capability based O/S, which does everything it needs to do fast enough in software - no special hardware required. Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117 #include <std.disclaimer>