pase@ogccse.ogc.edu (Douglas M. Pase) (09/16/88)
In article <1399@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: > >To me, the question is: Do the powers that be define exactly those >operators which are sufficient and cast all others (and the cpus) into >the Outer Darkness? Or do we provide access the hardware and an >appropriate encapsulation technique? This illustrates what seems to be a common misconception among a large share of the net. Language designers are *not* a Good Ol' Boys Club with vast and far reaching powers beyond the ken of mere mortals. They're not even trying to impede your best efforts. They're people with ideas that solve problems. Who are those great ``powers that be'' among language designers anyway? Backus? Kernighan? Ritchie? A sinister group of Frenchmen? Viscious rumormongers at Xerox PARC? I'll certainly admit that these are influential. But why are they influential? Because they had an idea (or, in the case of Backus, several ideas) that solved a lot of problems people were having. What's more, they were able to translate those ideas into a form that others would find useful (compilers, language descriptions, etc.). So, are you tired of waiting for the (all knowing, deeply respected, great and wonderful, totally awsome, thoroughly rad) ``powers that be'' to do what you tell them? Become a ``powers that be''!! (It takes little imagination to see why they're ignoring you -- they're too busy with new ideas of their own.) If your ideas are so great, (listening Herman?) just 1) write them up as a language proposal, 2) implement and distribute a compiler (with documentation, of course), or, 3) if you don't want to re-invent the wheel, put them together as a pre-processor package a la C++. If you can't do any of those things, then you have no effective means for communicating your ideas, and just maybe you don't know enough to know whether your ideas are as generally useful as you think they are. Ideas are popular because they solve problems, not because of some conspiracy designed to thwart you and promote someone else. The rhetoric so far has been interesting, but I feel no more enlightened about what language characteristics or features would satisfy those who complain the most. Much that has been said does seem to deal with isolated problems, but looks like, if implemented and used, it would cause other problems in their place (portability is most frequently cited). Shot from the hip of: -- Douglas M. Pase Department of Computer Science tektronix!ogccse!pase Oregon Graduate Center pase@cse.ogc.edu (CSNet) 19600 NW Von Neumann Dr. (503) 690-1121 x7303 Beaverton, OR 97006-1999
smryan@garth.UUCP (Steven Ryan) (09/19/88)
>Who are those great ``powers that be'' among language designers anyway? >Backus? Kernighan? Ritchie? A sinister group of Frenchmen? Viscious >rumormongers at Xerox PARC? I'll certainly admit that these are influential. It would be nice if they included users. > 1) write them >up as a language proposal, Sorry, can't do. My ideas are still ephermal. > 2) implement and distribute a compiler (with >documentation, of course), It's slow (symbol table is single chain), but it works. Documentation? Well, maybe, but if I document, I'll be violating all the manly traditions of Unix and nobody will take me serious. > or, 3) if you don't want to re-invent the wheel, >put them together as a pre-processor package a la C++. Ugh. Yucky. Garbage in, C out. What I want cannot be transformed into C, not in any simple fashion anyway. > If you can't do any >of those things, then you have no effective means for communicating your >ideas, and just maybe you don't know enough to know whether your ideas are >as generally useful as you think they are. Perhaps, but at least we're at the same level as everyone else here. So, put up or shut up? mode cell1: (m is mode) is begin priv pcell is var: (ref: (ref: m)) nil; op link as var: (ref: m) is pcell load as var: (ref: m); op var as var: m is pcell+1 as var: m; op cell as ref: m is pcell load as ref: m; op next as cell1:m is link load as cell1: m; op (dd is cell1: m) := (ss is ref: m) as cell1: m is (dd pcell:=(ss as ref:(ref:m)); dd); op (dd is cell1: m) := (ss is ref:(ref: m)) as cell1: m is (dd pcell:=ss; dd); op (dd is cell1: m) := (ss is cell1: m) as cell1: m is (dd pcell:=ss pcell; dd); op new:(v is m) as cell1: m is begin return is cell1: v; return:=(alloc:v width: ptr _width + v _width)ref; return link:=(ref: v) nil; return var:=v; return end; op drop is free: cell; op null is cell null; op est is cell est end; mode chain: (m is mode) is begin priv p is cell1: m; op null is p null; op est is p est; op curr is p var; op next is (p:=p link; p est); op new:(v is m) is begin new is p new: v; new link:=p link; p link:=new cell; void end; op drop is begin next is p next; p link:=next link; next drop; void end end; mode stk: (m is mode) is begin priv stack is cell1: m; pub op empty is stack null; pub op est is stack est; pub op top is stack var; pub op push:(v is m) is begin new is stack new: v; new link:=stack cell; stack:=new; void end; pub op pop is begin v is top load; x is stack; stack:=stack link; x drop; v end; pub op chain is stack as chain: m end; mode que: (m is mode) is begin priv head is cell1: m; priv tail is cell1: m; pub op empty is head null; pub op est is head est; pub op first is head var; pub op last is tail var; pub op add:(v is m) is begin new is head new: v; when head est then tail link:=new cell elwh head empty then head:=new cell nehw; tail:=new; void end; pub op push:(v is m) is begin new is head new: v; new link:=head cell; head:=new; void end; pub op pop is begin v is first load; x is head; head:=head link; when head empty then tail:=head nehw; x drop; v end; pub op pull is pop; pub op chain is head as chain: m end The generated code is very poor, but after all, it is a throwaway compiler so that I can get my thoughts in order. By the way, it defines two (among other things) polymorphics modes stk:m and que:m, so that I could do things like stk: (que: int), a stack of queues of integers. Not everybody can do this kind of stuff, though. So telling people to put up or shut up could be (1) embarassing when they do put up, (2) stifling because people with good ideas do not always enough skill to implement them. Eventually I hope to have a mode something like machine_integer which defines exactly those operators defined by the hardware and only those operators. Then a machine independent integer mode could be defined by mode int is begin using machine_integer; {use the same representation and operators as the hardware provides.} op (f is int)*(g is int) is {define multiplication, if, for instance, this is 6502 without any multiplication} ... end. >interesting, but I feel no more enlightened about what language characteristics It has to do with providing a rich set of primitive operator and abstraction facilities and then letting the peons define the operators they really need.