HDTenEightyP/NetNews huggingface dataset:
From: David.Beasley@cm.cf.ac.uk (David Beasley)
Newsgroups: comp.lang.pop
Subject: Re: Re: dlocals etc. (and shallow binding)
Date: 26 Jan 93 16:03:19 GMT
Organization: University of Wales College of Cardiff

In article <116670051@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
>If I write
>    constant foo = {'dog'};
>then the variable foo is immutable -- it always points to the same
>location.  

Unless, of course there is a subsequent line such as:
	constant foo = ['something else'];

Since you can easily redefine constants in this way, even these are mutable.

Using sysprotect("foo"); would provide an extra level of immutability,
but even then that does not prevent a subsequent sysunprotect("foo");
from making foo vulnerable again. I suppose ultimately, immutability 
is a matter of degree, which depends on the amount of effort required
to change the value to something else. The only totally unalterable 
variables are those stored in ROM!
--

David Beasley                          (David.Beasley@cm.cf.ac.uk)    
Department of Computing Mathematics 
University of Wales College of Cardiff                          __o
PO Box 916                                                      \<,   
CARDIFF    CF2 4YN                         ___________________()/ ()___
From: lpb@cs.bham.ac.uk (Luc Beaudoin)
Newsgroups: comp.lang.pop
Subject: Re: dlocals etc.
Date: 24 Jan 93 18:01:08 GMT
Organization: School of Computer Science, University of Birmingham, UK

sfk@otter.hpl.hp.com (Steve Knight) writes:

> The upshot of this is that Scheme achieves its lightweight continuations
> by forcing all (mutable) variables to be type-3 lexicals.  This is just
> shifting the work from one place to another, of course.  It makes good sense
> in Scheme because very few variables are mutable.  It makes poor sense in
> current day Pop because almost all variables are mutable.

Pardon my ignorance, Steve, but what do you mean by mutable?

Humbly,

Luc
-- 
-------------------------------------- -----------------------------------
Luc Beaudoin                          |  School of Computer Science
E-mail: lpb@cs.bham.ac.uk             |  University of Birmingham
voice:  +44 (21) 414-4766 or 3743     |  Birmingham B15 2TT, UK
Newsgroups: comp.lang.pop
From: pop@cs.umass.edu ( Robin Popplestone )
Newsgroups: comp.lang.pop
Subject: dlocals
Date: 25 Jan 93 18:08:52 GMT
Organization: University of Massachusetts, Amherst
Originator: pop@roo.cs.umass.edu

> But of course, you have to keep changing the definition of the
> structure Env for different purposes, which can makes reuse of code
> difficult.


This of course is missing the point of functional abstraction - POP in some
sense has no data-structures, only functions. So you can just extend
environments by introducing new selector functions. The trouble with this
approach is of course the *constructor functions* which have an arity that
is specific to a particular application.

A useful approach to dealing with this problem is to introduce constructive
ways of changing individual components of a data-structure (I usually call
them with_X - eg  L with_hd 2  is the list L with its head constructively
replaced by 2). I think that something similar is talked of for ML.

Alternatively, you can make environments be properties which map names to
values.

>Also when the environment changes you either have to use
> dlocal anyway, to ensure that it is automatically reset whenever
> procedure exit occurs, or else you have to copy the structure on
> entry to any procedure that can change it.

Well...there is profit for many applications in using POP as a
functional-language-toolkit, in a style in which you write you topmost
layer (the user interface) and your bottom layer (*your* primitive
functions) in a non-functional way, but write the rest in a pure functional
form. This means in particular that you obtain log times for
the incremental computations of tree-to-tree functions via memoisation.
All problems of algebraic simplification and compilation are much eased by
such an approach (algebraic simplification is usually conducted in some
kind of environment - e.g. what order to sort the variables, whether to
apply distributivity, trig. identities...). In particular, one would be
able to perform log time incremental compilation of context-sensitive
languages like ADA, instead of the linear time compilation characteristic
of conventional compilers. (...for changes that didn't involve a change to
a global declaration that is...).

Generally, I think the world made a big mistake when it went for the likes
of C as a systems language, and regarded a system like Multipop as the
muddling along of amateurs. I believe that decent functional abstraction
could (e.g.) provide flavours of X that are efficiently local or
distributed as required by an application, and that the uniform checking
mechanisms of POP avoid inefficiencies arising from non-uniform checking
mechanisms that C programmers are forced to hack up. But some of the things
you can get with NJML (and that they are actively exploiting in CMU) do
require that variables be lexical.



Robin
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Wed, 27 Jan 1993 14:23:26 GMT
Subject: Re: Re: dlocals etc. (and shallow binding)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.pop


The discussion about definable constants (or not) reminds me of the
similar situation in Pepper. I intend Pepper to be used interactively,
in the same way as Pop, and yet wish to avoid some of the strange effects
(such as redefinable constants).

The Pepper solution is this. First, there are two kinds of declarations,
``val'' and ``var''. Identifiers declared by ``val'' are not assignable
(the declaration initialises them), while those declared by ``val'' are.

[Quickly scanning the Pepper code to hand, I see more than 750 ``val''s 
and less than 250 ``var''s. These figures are distored in favour of
``var'' (yes, in *favour* of *vaR*) because (a) var's tend to appear
at top level, (b) there are two very similar large programs in my
sample, which both (c) use var's to cope with the bootstrap compilers
inability to have top-level val declarations with run-time initialisation
values.]

Names are redefinable (``fluid'') or not (``static''; these terms are
not fixed, not least because the compiler doesn't do this yet!). 
Redefinable constants (val's) are just like variables, except for being
unassignable; that is, when they are redefined, everyone sees the new
value (unlike Pop constants). Unredefinable constants get their values
compiled into the code.

Qualifiers on declarations allow the programmer to choose between
re- and unre- definable. The default in interactive use is re-; for
batch compilation, it is unre-. (Just as well, because the bootstrap
compiler doesn't allow any sort of redefinition.)

Thus you can never over-ride a static val's value, and a fluid val's 
value is subject to change without notice. There will be a way to 
pick the default qualifier, so you can make an interactive compilation
get you static val's. The effect of Pop's ``protected'' will probably
be obtained by the as-yet-vague module system.


--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods
From: pop@cs.umass.edu ( Robin Popplestone )
Newsgroups: comp.lang.pop
Subject: Folding in VED
Date: 25 Jan 93 18:43:14 GMT
Organization: University of Massachusetts, Amherst
Originator: pop@roo.cs.umass.edu


> Before this glorious future arrives, there is one feature I would love
> to have incorporated into VED as soon as possible -- and that's
> folding.  I'm always frustrated that when I'm writing a large program
> I can't collapse a bunch of related functions togther into a single
> line.  I thinking that text "folding" (as in the original OCCAM editor)
> could well add something special to VED.

It is always a mistake to pronounce something "hard". But it seems to
me that there is a real problem here, namely the mapping between screen
space and buffer-space. In VED (unlike EMACS) a buffer is conceptually
2-dimensional (EMACS has a 1-dimensional model of a buffer as a string,
which is no doubt optimised behind-the-scenes). Thus the mapping from
buffer space to screen space in VED is a linear transform (if you play the
old projective-geometry hack of homogeneous coordinates). This is deeply
built into VED. Folding would of course change the mapping.

Similar probems arise with a system like Pantechnicon. Here, each logical
sub-unit has an associated size, and the mapping from buffer-space to
screen-space requires a recursive descent through the hierarchy (do-able in
log time if there is a bound on the tree-branching-ration).

Robin
From: ray@philmtl.philips.ca (Ray Dunn)
Newsgroups: comp.lang.pop
Subject: Re: dlocals etc. (and shallow binding)
Date: 26 Jan 93 03:39:34 GMT
Organization: Not Philips.

In refd article, axs@cs.bham.ac.uk (Aaron Sloman) writes:
>A really "clean" implementation would have required all local
>variables to have their values initialised to some safe default on
>procedure entry, e.g. to "undef".

..and to take advantage of internal knowledge of the fact that it doesn't
raises the hackles of anyone concerned about "future release surprise" or
portability!

>    define print_procedure( ..... );
>        dlocal printlevel = printlevel + 1;


looks pretty bogus to me.  I've been trying to teach programmers to avoid
this sort of thing for years.  POP-2 was quite clear about it, even though
this code would "work".  The reference manual states that when the extent
of another variable is interrupted "its value is not altered but it cannot
be accessed or changed by assignment."

>The alternative to these dynamically scoped uses of printlevel and
>popmatchvars (and similar things, like interrupt, cucharout,
>prmishap, etc.) would have been to require all these values to be
>passed explicitly as extra arguments in any procedure that might
>call a procedure that used these values, or else to do what Robin
>does, namely:
>
>> My own practice these days is to avoid any dlocals in code I actually
>> write, by using an extra argument to any function (usually called "Env")
>> which is a data-structure that bundles up any kind of style switch.

In 'C' the effect can often be achieved by using a _static_ variable, but
my own technique is to use a pair of functions - the outer function
presents a "clean" interface to the outside world and calls a second
function with all the required extra arguments - it is this second function
that recurses.

So Aaron's example becomes (ha! I'll do it in POP-2ish)

    vars max_printlevel;
    5 -> max_printlevel;

    print_procedure(....)
        aux_print_proc(..... , 1);
    end

    aux_print_proc(..... , printlevel)

        if printlevel >= max_printlevel then
            ... print closing bracket and return ....
        else
            ... print suitable opening bracket ....
            aux_print_proc(whatever tail of structure, printlevel+1);
        close
    end

Now who has a compiler I can syntax check this with!!
-- 
Ray Dunn at home        |  Beaconsfield, Quebec  |  Phone: (514) 630 3749
ray@philmtl.philips.ca  |  ray@cam.org           |  uunet!sobeco!philmtl!ray
Newsgroups: comp.lang.pop
Newsgroups: comp.lang.pop

Following on from Chris's comments about "vals" and "vars".  
> [Quickly scanning the Pepper code to hand, I see more than 750 ``val''s 
> and less than 250 ``var''s. These figures are distored in favour of
> ``var'' [deleted]

Even this is an underestimate in the ratio between val/var, which I reckon
is probably more like 10:1 rather than the noted 3:1, because Chris omitted
to mention that all input locals and loop variables are declared as val
by default.

My own experience of the val/var distinction is extremely positive.  Here's
a (elderly) example drawn from $popautolib (the comments are my own).

    define global countitem(file) -> x;       ;;; global is soon to be obsolete
    lvars c white = false, file x = 0;        ;;; obsolete syntax.
        discin(file) -> file;
        until (file() ->> c) == termin do
            if strmember(c, '\s\t\n\r') then
                unless white then
                    x fi_+  1 -> x;           ;;; not safe for v. large files
                    true -> white             ;;; (greater than 1Gb)
                endunless;
            else
                false -> white
            endif;
        enduntil
    enddefine;

In the above code, it is not obvious what variables are playing the role
of state variables and which are just placeholders for intermediate
quantities.  Here's the same code in a "Pepper" style.

    define countitem( file ) -> var x;          ;;; The var declaration makes
        0 -> x;                                 ;;;  dubious practice stand 
        false -> var white;                     ;;;  out.
        for c from_repeater discin( file ) do   ;;; Here, c is a -val- !
            if strmember( c, '\s\t\n\r' ) then
                unless white then
                    x + 1 -> x;
                    true -> white
                endunless;
            else
                false -> white
            endif
        enduntil
    enddefine;

Note how the 2 var declarations pin-point the genuinely changing variables.
Also note that the assignment ``discin( file ) -> file'' has been removed
using the new loop syntax for repeaters.  (This is just a more modern
phrasing of the same idiom.)  The val/var annotations, to my mind,
really enhance the look of the procedure for the reader, provide useful
protection for the writer, and even make the compiler writer's job
slightly easier.

In this example there is a high proportion of 'var-types' (2 of 4) because the
problem chosen deals with state change.  This reflects the coding style.
More commonly, we find libraries such as flatten, gensym, pipein/out, 
which, as it happens, contain no variables that need to be var-type.

I've become a convert to the Pepper style of declarations.  I believe
that once people try them, they'll all be clamoring for them!

Steve
From: sfk@otter.hpl.hp.com (Steve Knight)
Date: Thu, 21 Jan 1993 18:23:20 GMT
Subject: Re: dlocals etc.
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.pop

Robin Popplestone writes:
> To this day we can't compete with Scheme and JNML in generating
> light weight continuations.


Scheme continuations are not quite the same thing as Pop processes regardless
of issues of dlocalisation.  In particular, Pop processes take copies
of the dynamic environment (i.e. copies the callstack) and Scheme
processes do not.

The upshot of this is that Scheme achieves its lightweight continuations
by forcing all (mutable) variables to be type-3 lexicals.  This is just
shifting the work from one place to another, of course.  It makes good sense 
in Scheme because very few variables are mutable.  It makes poor sense in
current day Pop because almost all variables are mutable.

Unfortunately, POP-11 doesn't implement environment copying perfectly.  Type-3
lexicals are not copied -- but shared between different processes.  This
is a known defect in Pop processes.

Steve
From: sfk@otter.hpl.hp.com (Steve Knight)
Date: Mon, 25 Jan 1993 12:02:32 GMT
Subject: Re: Re: dlocals etc. (and shallow binding)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.pop

Luc asks:
> Pardon my ignorance, Steve, but what do you mean by mutable?

Allowed to change -- the inverse of constant.  Most variables in Pop
are updated more than once in their dynamic lifetime and are therefore
intrisincally mutable.  Some variables are allowed to change but provably
are never assigned to more than once -- they are potentially mutable but
can be treated as immutable (i.e. constant).

There is an ambiguity over whether (im)mutability just applies to the top-
level of a datastructure or all levels.  e.g. If I write
    constant foo = {'dog'};
then the variable foo is immutable -- it always points to the same
location.  However, its value is mutable. i.e.
    'cat' -> foo(1);
is legal and changes the value of foo.  So the question is whether it is
really proper to talk of foo being immutable when it value can change?  In
Pop, it turns out that the best way to use the term immutable is to only
be concerned with the top-level.  This is because there are so few data
structures in Pop which are non-assignable, the other usage would never
apply.

Hope this helps!

Steve
Newsgroups: comp.lang.pop

There's been quite a lot of discussion about the role of VED in Poplog
recently.  While I certainly agree with the emacs-lovers that Poplog 
should be properly integrated with emacs, emacs is not the program
development environment I'm looking for.

I think the newly added ability to display text with bold, italic, 
underlining (etc) is the right way forward for VED.  I would like to
see VED developing into a word-processor or DTP like system.  And I 
would like those facilities integrated into the system so I can apply 
them to programs as well as help files.  Emacs is a great system for 
manipulating text files.  VED's future doesn't lie in that direction, 
in my view, but in the extension to full DTP status.

Before this glorious future arrives, there is one feature I would love
to have incorporated into VED as soon as possible -- and that's 
folding.  I'm always frustrated that when I'm writing a large program
I can't collapse a bunch of related functions togther into a single
line.  I thinking that text "folding" (as in the original OCCAM editor)
could well add something special to VED.

Does anyone know how difficult it would be to add this to VED?  I'd really
like to see it.

Steve
From: pop@cs.umass.edu ( Robin Popplestone )
Newsgroups: comp.lang.pop
Subject: EMACS and POP
Date: 27 Jan 93 00:13:22 GMT
Organization: University of Massachusetts, Amherst
Originator: pop@roo.cs.umass.edu

There is an improved version of the EMACS - POPLOG interface which was done
here by Gordon Dakin. This "knows" that POPLOG has 4 languages (not a
natural concept to EMACS). I did send it across the Atlantic some time ago,
but don't know if it will be in contrib for 14.2.  It will work in
conjunction with XVED to give access to help files (I don't know why people
like EMACS but they do...). Gordon Dakin has bashed it hard (at least the
Prolog and POP interface), since he is one of the ones who likes EMACS.

Robin.
Date: Fri, 22 Jan 1993 09:48:00 CET
From: marcus_olk@cl-hh.comlink.de
Reply-To: marcus_olk@cl-hh.comlink.de
Distribution: world
Newsgroups: comp.lang.modula2
Subject: Another JPI Compiler bug?
Organization: Freies Telekommunikations-Zentrum Hamburg e.V.
Content-Length: 1548    
X-Gateway: NETCALL3.8 UC xclhh.comlink.de [UZERCP V3.99d]

I'd like to ask the people using JPI-M2 to test the following:

Select the project MWDEMO.PR and run make on it. Try to execute the
compiled MWDEMO.EXE under MSW - it should work.

Now, set [Project][Project options...][Calling convention] to stack
and re-make the demo. The linker should report

Error: File not found
File: wsfcom.lib

We can't find this library on our distribution disks (Env,M2,Tech-kit).

And now, reset the calling conventions to jpi and set [Project]
[Optimization options...][Coprocessor] to emu for 87-Emulation. I'm
using an 386SX, so I have to set this switch. Edit the file MWMAIN.MOD
declare a REAL variable and assign an arbitrary real value to this
variable, e.g. in procedure WinMain:

...
VAR
  test : REAL;
  ...
BEGIN
  test := 0.0;
  ...

Re-make the demo-project and try to execute the new binary under MSW.
On my system, this leads to lock-up MSW. After a reboot you might try
to set the winmath symbol in the project-file from "none" to "emu".
When you re-make the project you'll get the linker report

Error: File not found
File: win87em.lib

We can't find this lib, either. I'd like to know if you can confirm
these problems.

Thanks in advance,
Marcus

--
 Marcus Olk        # Internet: olk@informatik.uni-hamburg.de
 Schwalbenweg 9a   #           marcus_olk@cl-hh.comlink.de
 D-2000 Hamburg 61 # Zerberus: MARCUS_OLK@CL-HH.ZER
`Wer sagt, dass man Glueck nicht kaufen kann, hat keine Ahnung von Shopping'
                                                          --- David Lee Roth



## net_sh v1.6 (sb)
From: smith@ctron.com (Lawrence C Smith)
Newsgroups: comp.lang.modula2
Subject: Re: c and m2
Keywords: c, m2
Date: 26 Jan 93 18:12:45 GMT
Reply-To: smith@ctron.com
Organization: Cabletron Systems, Inc.

In article <1993Jan25.184552.23393@mcshub.dcss.mcmaster.ca>, cs4gp6au@maccs.mcmaster.ca (Lockie      RJ) writes:
>/* p now points to test[1] according to K&R2 pg. 98 */
>  (* p now points to test[0][1] *)

>So, if the above code is correct, the question I have is why does
>incrementing a pointer in C point to the next element in the array?
>while in Modula-2 it doesn't (the pointer needs to be incremented
>by the size of the array element).

>How does C do that? Is it the compiler? In Modula-2, to increment to
>the next element in the array it would require:

>  INC( p, SIZE(ex) );

The main difference between B and C is the notion of types.  B just had
words, C had ints, and chars, and so on.  One of the original reasons for
this change was so that the compiler could recognize pointer to <type>
and increment by the appropriate number of bytes to get to the next
element.

The reason this is so is because arrays are second-class citizens in C,
merely vectors of elements, not a real type, like structs are.  You can
see this in every function call, where an array is always passed by address
(even the name is merely a constant referring to the address of the first
element) and a struct is actually copied onto the stack, like any other
parameter.  Vectors were set up so the programmer could scan them by walking
a pointer up and down - in fact, C is completely designed around this
assembly-code concept.

Modula and Pascal promote arrays to first-class citizens, they are treated
just like records and they define _subscripting_ as the access mechanism,
_not_ pointer dereferencing.  When you inc or dec a pointer you are poten-
tially breaking typechecking by potentially breaking range-checking.

Modula's INC builtin is defined to increment its argument by one, no more.
It is _not_ defined as a means of stepping to the next "reasonable" value.
It is _not_ a pointer operation.

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
Liberty is not the freedom to do whatever we want,
it is the freedom to do whatever we are able.
From: csfraw@vehka.cs.uta.fi (Francis Akoto)
Newsgroups: comp.lang.modula2
Subject: pascal code to modula
Date: 22 Jan 93 10:57:03 GMT
Reply-To: csfraw@vehka.cs.uta.fi (Francis Akoto)
Distribution: world
Organization: University of Tampere, Finland

This is a pascal code

   i,j: integer ;

		  i := i or j ;

what will be ite equivalent in modula-2 ?

email answer to me :csfraw@vehka.cs.uta.fi

thanks

     
--
gallows
     Opinions are like assholes;
     Everybody has one but nobody wants to look at the others.
From: cspt@giraffe.ru.ac.za (Prof. P. Terry)
Newsgroups: comp.lang.modula2
Subject: Re: pascal code to modula
Date: 23 Jan 93 09:39:34 GMT
Article-I.D.: giraffe.cspt.62.727781974
Organization: Rhodes University, Grahamstown, South Africa

In article <1993Jan22.163533.8577@psg.com> randy@psg.com (Randy Bush) writes:

>csfraw@vehka.cs.uta.fi (Francis Akoto) writes:
>> This is a pascal code
>>    i,j: integer ;
>>    i := i or j ;
>
>That most certainly is *not* Pascal code.

I agree, Randy.  But Francis probably believes that TurboWhatsit *is* Pascal
(like some folks are going to believe ISO M-2 is Modula-2?)