🚀 go-pugleaf

mwm@eris.berkeley.edu (Mike (I'll think of something yet) writes:
>In article <4495@crash.cts.com> wade@pnet01.cts.com (Wade Bickel) writes:
><        So far I have found nothing I could do in C that I could not do in
><M2.  To me this is the test of a Language.
>
>You're not looking very hard. Please translate the following C
>construct into M2:
>
>	short main[] = {1, 2, 3} ;
>

Sure,

        main : ARRAY[0..2] OF INTEGER;

        main[0] := 1; main[1] := 2; main[3] := 3;

Pre-initialization is a nicety, not allowed in M2 because there is no way to
type the data.  This is a restriction that I understand will be/has been
lifted.  However, pre-initailization is not a conceptual tool.  It can always
be translated to a series of assignments, or a number of other methods can
be used to init data.

>On hardware that supports it, this sets up three words, puts the
>values 1, 2 and 3 into them, and arranges to branch to that location
>under the right conditions. Likewise, can you write M2 code that
>_will_ generate an address exception? Both of these features were used
>in the Unix kernel at one point in the past. 
>

        I don't see how the code you've listed arranges the branch, so perhaps
I am missing something, but since I understand the code you've listed, I think
it unlikely.

        Yes, M2 can be used to generate and deal with address exceptions.  The
new Benchmark debbugger does so.

>Of course, if you don't need to do these kinds of things, then you
>don't care about them. So C may not be the language of choice for the
>problem at hand. And that's my test of a Language - how do the idioms
>of the problem I'm solving map to it.
>
>Finally, from elsewhere:
>
>>> In fact, if you declare a function (or a variable external to a function)
>>> to be static, it will be local to the source file but global to all functions
>>> within that file. 
>
>Not quite. C (like many other languages) reqiures forward
>declarations.  Functions and variables are only visible to code that
>occurs after their decleration in the file. And an external variable
>declared in a function only has function scope in ANSI C. In pre-ANSI
>C, the scope wasn't explicitly defined, and PCC based compilers gave
>it file scope.
>

        Besides, as I have already pointed out, static variables do not cut it
as they will not generate a new level of locals on a recursive call.  The
whole point of nesting is to create an autonomous sub-environment which can
be called recursively forces such an environment to be restricted to a
single routine.

        The "declare static variables" solution that keeps cropping up does
not work.

        As I said before, what bothers me most about this is that I can see no
reason why C does not support this feature.  Perhaps Lattice or MANX will add
it, since the only hit would be that the programs written using nested sub-
routines would not be portable to other compilers.  If portability is an
issue, the coder could simply not nest any subroutines.  In the meantime I
could get back to writing shorter, neater initialization and data search
routines using nesting.  Alternatively someone could point out some good
reason why C does not support nested routines?


                                                        Thanks,


                                                                Wade.
PS:  Please, send me Email if you do not have a solution to the problem I
        posted, i.e. a lack of the ability to nest subroutines in C.  I had
        hoped it would be possible, and am quite dissapointed that it is not.
        At this point I am more interested in how to introduce it into the
        C language than arguing whether C is better or worse than M2.  How
        do I make a request to the ANSI commitee?


UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!wade
ARPA: crash!pnet01!wade@nosc.mil
INET: wade@pnet01.cts.com