Path: news.daimi.aau.dk!news.uni-c.dk!sunic!news.luth.se!eru.mt.luth.se!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!agate!news.Stanford.EDU!Xenon.Stanford.EDU!agesen
From: agesen@Xenon.Stanford.EDU (Ole Agesen)
Newsgroups: comp.lang.beta
Subject: Re: Pattern variables
Date: 11 Feb 95 23:02:06 GMT
Organization: Stanford University: Computer Science Department, CA USA
Lines: 91
Message-ID: <agesen.792543726@Xenon.Stanford.EDU>
References: <ALFH.95Feb6184811@byleist.ifi.uio.no>
NNTP-Posting-Host: xenon.stanford.edu
X-Newsreader: NN version 6.5.0 #4 (NOV)


Affi (alfh@byleist.ifi.uio.no (Alf-Ivar Holm)):

You posted two similar programs for composing integer functions, one 
using dynamic object references to represent functions, the other 
using "dynamic pattern references" (or pattern variables as they are 
officially called).
Then you asked:

> Can someone please enlighten me on why pattern variables is the
> thing to use in this context?

Regarding the specific example, I don't think any one construct is
THE thing to use. Perhaps if your functions were more complicated than
just x+x and x*x, perhaps if they had state, perhaps if it was a more
complicated operator than simple composition, maybe one that evaluted
the functions several times, perhaps then one or the other 
representation would be "better". 

What does "better" mean here? Or more generally why is it necessary 
(or rather desirable) to have pattern variables in Beta? Can't we 
just always use dynamic object references, say? 

Yes, probably. But then we could also "just" program Turing machines.
When designing a language, an important goal is to be able to express
direct, extensible, maintainable, concise solutions to problems and at
the same time avoid having a large complicated language. 
Orthogonal concepts and few restrictions on how they can be combined is
the established way to achieve the goal. For example: 
      - We want static and dynamic references. 
      - We want references to patterns and to objects. 
Now, should references to patterns be restricted to being static? 
Of course not.

Btw, Bjarne Stroustrup once wrote something about the difference 
between a language being able to simulate a style of programming
vs. support a style of programming. C can simulate OO programming,
using function pointers or if-statements to do dynamic dispatch. C
can not, however, be said to support OO programming. I think that it
can be argued that there is a similar distinction between having 
pattern variables vs. not having them. That is, dynamic object references
can be used to simulate pattern variables; you can not say that they
support the style of programming that pattern variables do.
(Bjarne: sorry if I'm using the words "simulate" and "support" in the 
wrong way. I no longer have the paper).

Ole, agesen@cs.stanford.edu


P.S. Affi's programs:
   ORIGIN '~beta/basiclib/current/betaenv';
   --- PROGRAM : descriptor ---
   (#
      intFunc: (# x,y: @integer enter x do inner exit y #);

      comp:
        (# f,g: ##intFunc; h: intFunc(# do x -> f -> g -> y #)
        enter (f##, g##)
        exit h##
        #);

      a: intFunc(# do x+x -> y #);
      b: intFunc(# do x*x -> y #);
      ab: ##intFunc;
      in: @integer;
   do
      (a##, b##) -> &comp -> ab##;
      'In: ' -> putText; getInt -> in;
      'Out: ' -> putText; in -> ab -> putInt; newline;
   #)

    ORIGIN '~beta/basiclib/current/betaenv';
    --- PROGRAM : descriptor ---
    (#
       intFunc: (# x,y: @integer enter x do inner exit y #);

       comp:
         (# f,g: ^intFunc; h: intFunc(# do x -> f -> g -> y #)
         enter (f[], g[])
         exit &h[]
         #);

       a: intFunc(# do x+x -> y #);
       b: intFunc(# do x*x -> y #);
       ab: ^intFunc;
       in: @integer;
    do
       (&a[], &b[]) -> &comp -> ab[];
       'In: ' -> putText; getInt -> in;
       'Out: ' -> putText; in -> ab -> putInt; newline;
    #)