HDTenEightyP/NetNews huggingface dataset:
From: mg@elan (Michael Golan)
Newsgroups: comp.lang.c++
Subject: Re: Which compilers have templates/exceptions?
Date: 7 Nov 92 11:08:27 GMT
Organization: Princeton University, Dept. of Computer Science

newkerk@dirac.zso.dec.com (Oscar Newkerk) writes:

>> 
>> 			Templates				Exceptions
>> Borland V3.1		partial (no friend classes)             none
>> Microsft CV7		none					macros (poor)
>> Zortech V?		none?					none?
>> 
>> 			Thanks,
>> 				Sieg
>> 

>DEC C++			Yes					Yes

cxx was just installed here. I don't know which version, of course,
since cxx -V nor -v nor the man page would tell. It does "support"
templates, but!	(It is symlink to cxx2.1 so that might be the ver num)

The first thing I tried (honest!) was:

#include <stdio.h>
class X {
	int x ;
public:
	X operator+(X b) { return x+b.x ; }
	void print() { printf("%d\n",x); }
	X(const int n=0) :x(n) {} 
	X(const X& v) { x=v.x ; }
};
main()
{
  X u(3),v(2),w ;
  u.print();  v.print();
  w=u+v ;
  w.print();
}


Then, I compiled with -O -S and took a look at the output. 
It *runs correctly*, but the compiler's sense of the required frame size
and the use of registers and temporaries shows either serious bugs or a
really (really) bad compiler.

The 2nd program I tried (ok, I narrowed it down to this :-):

class S { public: S(const char *x) {} };

class T { public:
    operator const char*() const{}
    void ok(const T& s) { S tmp(s); }		// fine

    class subT { public:
        void bug(const T& s) { S tmp(s); }	// wont compile, DEC C++ bug:`
  //: error: In this declaration, the argument list "(s)" matches no "S::S".
    };
};

Then I gave up and went back to C :-(
  Michael Golan
  mg@princeton.edu
Newsgroups: comp.lang.c++
From: syackey@ccscola.Columbia.NCR.COM (Steve Yackey)
Subject: Re: something nasty
Organization: NCR Corp, E&M-Columbia, Columbia, SC
Date: Fri, 06 Nov 92 15:55:23 GMT

In article <540@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <1992Nov1.224626.771@BofA.com> dan@BofA.COM (Dan Brockman) writes:
>>
>>If you can explain this, please send me email and
>>tell me how to fix my code so it runs.
>>
>>---------------- the big nasty --------------------
>>
>>
>>"Dbasesw.c", line 1842: internal <<AT&T C++ Translator 
>>2.1.03 08/31/90>> error: bus error (or something nasty
>> like that)
>
>1) I have seen this (SCO ODT, HCR C++ compiler).  No rhyme or reason
>	that we've ever been able to determine.  Sometimes just simple
>	syntax errors.
>
>2) You did't give us the code w/ the problem (which may or may not
>	have helped...)
>

the magic fix (works here) is to take the entire function, i.e., stuff
between the {}, that has the error, line 1842 in this case, yank it out
and stick it at the top of the source file.

have no idea what this does, but it has always worked.

Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: member test?
In-reply-to: haechler@bernina.ethz.ch's message of 6 Nov 92 08:16:58 GMT
Date: 9 Nov 92 08:53:35
Organization: Ascent Technology, Inc., Cambridge Massachusetts

In article <1992Nov6.081658.29693@bernina.ethz.ch> haechler@bernina.ethz.ch (Stefan Haechler) writes:

   How can I know which dynamic type has a variable ?
   e.g.
   class A { .... } ;
   class B: public A { ... } ;
   // variable declaration 
   A *a ;
   // initialization
   a = new B;
   // now the dynamic type of "a" is B
   // my question:
   // is there a statement for testing if a is member of B
   // e.g 
     if (member(a,B) == true) ..... else ..... ;


[I tried to reply via E-mail, but it bounced.]

You are asking for something called "runtime type identification" or
RTTI, which has been much discussed in the C++ community and may
eventually make it into the language in some limited form.  But the
answer for now is that no, you can't do it, unless you implement it
yourself by using some type of virtual function that you redefine in
each subclass.

The software-design answer is that you shouldn't have to know the
answer to this question, and that there may be something wrong with
the design if you need to ask it.  If you know only that something is
a pointer-to-A, you should be using only the methods and virtual
functions that are part of the interface defined by class A.

In the case where you know about subclass B while class A is being
designed, and where the notion of possible B-ness is part of the
design of class A, you should have a virtual function

class B;

class A { ... virtual B* asB() { return 0; } ... };

class B : public A { ... B* asB() { return this; } ... };

which is type-safe and doesn't involve any nasty casts.


Newsgroups: comp.lang.c++
From: donovan@well.sf.ca.us (Sean Donovan)
Subject: Re: Borland Debugger/Win3.1 question
Organization: Whole Earth 'Lectronic Link
Distribution: usa
Date: Fri, 6 Nov 1992 07:47:35 GMT

In article <Bx7CsB.KIy@Interlan.com> consigli@interlan.interlan.com (Frank Consiglio) writes:
>Hi everyone.  Question: does the debugger included in Turbo C++ v3.0 
>for Windows operate under MS Windows v3.1?  Windows is reporting a DLL
>missing when I try to install the debugger under Win3.1.
>
>Feel free to send mail with any relevent experiences.  Thanks.
>
>Frank C.


TDW which ships with bcc 3.00 will run under win 3.1 if you have the correct
version of WINDEBUG.DLL which is available with bcc 3.10 and from 'other'
sources, (I got my copy before I upgraded from someone who went to the win
developers conference this past may.)  With the new version of windebug
installed tdw ran fine.

Sean Donovan
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 11 Nov 1992 18:15:20 GMT

In article <klamer.721303355@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
>In <1992Nov7.155248.23401@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>]In article <klamer.720538594@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
>
>]>OK, that holds for global / static variables. But how for auto variables?
>]>These generally are efficient to use, but to be efficient, their size
>]>must be known at compile time. 
>
>]	Why? Why cant the size be calculated by a smart linker
>]at link time? Why cant assembly output be made by the compiler
>]with 'sizeof_someobject' as a symbol yet to be determined?
>
>]>and thus can only a pointer to an object on the heap be used.
>
>]	NO, and I have SEEN it done otherwise in a Modula compiler,
>]I used it and it worked.
>
>I doubt it. I can't see how a compiler can build a stack frame with
>auto variables, if the sizes of the elements on the stack frame are
>unknown. 

	The Modula compiler looks up the last definition of the type
and uses the size of that. If subsequently the system finds that
its been changed, auto-dependency checking causes the module
to be re-compiled.

	As I said before this requires environment support to
work, and is unlikely to be workable for C++ which doesnt have
the ability to pre-compile a class interface declaration.
Modula has separate INTERFACE and IMPLEMENTATION sections
for modules and it is possible to do this. Modula *requires*
environment support because it has a USE MODULENAME statment,
whereas C has #include filename. Modula has to associate
the internal MODULENAME with an external file containing
the precompiled module interface anyhow.

	So thats how it works. It was done deliberately to
avoid using a pointer on the stack.



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis)
Newsgroups: comp.lang.c++
Subject: return statement
Date: 12 Nov 1992 14:08:26 +0200
Organization: Institute of Computer Science, FORTH Hellas
NNTP-Posting-Host: antigone.csi.forth.gr
Summary: what about return int i?
Keywords: c++ return

 i wanted to do an example,so I wrote:
int ff()
{return int i;
}

g++ errors.
Is that a correct statement?
From: ptb@eng.cam.ac.uk (P.T. Breuer)
Newsgroups: comp.lang.functional
Subject: Re: Functional Parsers
Keywords: parsers
Date: 10 Nov 92 17:01:23 GMT
Organization: Cambridge University Engineering Department, England

>In article <1992Nov3.160104.5305@odin.diku.dk> torbenm@diku.dk
>(Torben AEgidius Mogensen) writes:
>>ptb@prg.ox.ac.uk (Peter Breuer) writes:
>>
>>>There is also a paper by Jonathan Bowen and myself (which I think has
>>>[...]
>>
>>Does this parser generator handle non-LL languages?
>
>I don't mind admitting that I don't know what a non-LL language looks like.


Thanks to Debora Weber-Wulff for offering a test case.
The language { a^n b^n | n>=0 } apparently definitely has no LL grammar
(but does have a LR(0) one) and is specifiable in pre-cc. But not all
LR(0) grammars are acceptable for precc, because LR(0) presentations can be
left recursive. I think all LR(0) languages are expressible, though,
if you choose the right grammar presentation.

two specifications:

(1) not using attributes

@ S = AB $

@ AB = a AB b
@    | a b

(2) using attributes

@ S = as\n b*n $

@ as = a as\n @n+1
     | a      @1

The latter is the more powerful technique, since it is computationally
complete, as I showed by specifying an interpreter for occam object
code. Admittedly, that was the worst possible example to choose! But
it's the basis of my claim that LR(0) languages are expressible.

If you want the functional programming interpretations, then (using the
operator notation from graham hutton's soon-to-be JFP paper - see this
thread)

(1)   S = AB $then EOL

      AB = (a $then AB $then b) $alt (a $then b)

(2)   S = as $into (n -> bs(n) $then EOL)
      
      as = (a $then as $into (n -> success(n+1)))  $alt (a $then success 1)

      bs(n) = b $then bs(n-1) , n>1
            = b               , otherwise

Has anyone done a speed comparison of the pure combinator approach (aka
Wadler (1985), Fairbairn (1987), etc.)  versus combinators which build new
state machines from old, Using cross products of the state spaces, and
so on?

Peter
Newsgroups: comp.lang.functional
From: joe@erix.ericsson.se (Joe Armstrong)
Subject: Re: Is efficient backtracking feasible in functional languages?
Nntp-Posting-User: joe
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Wed, 11 Nov 1992 17:17:42 GMT


|> 
|>    strangesucc n =	hd [x|x<-[0..];x>n];
|> 
	....
|> 
|>   - Stream.head(Stream.filter(fn x => x > 1000000,Stream.iota()));
|>   
|>   [Major collection... 21% used (3397260/15733684), 1920 msec]
|>   
|>   [Major collection... 21% used (3397288/15730836), 1910 msec]
|>   
|>   [Major collection... 21% used (3397288/15730948), 1920 msec]
|>   
|>   [Major collection... 21% used (3397288/15730888), 1920 msec]
|>   
|>   [Major collection... 21% used (3397288/15730888), 1910 msec]
|>   val it = 1000001 : int
|>   -

	Wonderfull  !!

	This is the kind of stuff that gives FP a bad name :-)

	Is their a transformation system which can prove that

	strangesucc x == x + 1 ?

	Joe


Newsgroups: comp.lang.functional
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: Is efficient backtracking feasible in functional languages?
Date: 12 Nov 92 12:23:50
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: staffan@chivas.Eng.Sun.COM's message of 11 Nov 92 21:53:37 GMT

Someone wrote:

anon> strangesucc n =	hd [x|x<-[0..];x>n];
anon> [this runs out of memory and uses space linear in n]

I replied that there is no reason why this should use space linear in n:

tmb> - Stream.head(Stream.filter(fn x => x > 1000000,Stream.iota()));
tmb> 
tmb> [Major collection... 21% used (3397260/15733684), 1920 msec]
tmb> 
tmb> [Major collection... 21% used (3397288/15730836), 1910 msec]
tmb> 
tmb> [Major collection... 21% used (3397288/15730948), 1920 msec]
tmb> 
tmb> [Major collection... 21% used (3397288/15730888), 1920 msec]
tmb> 
tmb> [Major collection... 21% used (3397288/15730888), 1910 msec]
tmb> val it = 1000001 : int
tmb> -

In article 18783@eua.ericsson.se, joe@erix.ericsson.se (Joe Armstrong) writes:
joe> 
joe> Wonderfull  !!
joe> 
joe> This is the kind of stuff that gives FP a bad name :-)

It only gives "FP a bad name" if you intepret this naively. The
performance of the SML implementation that I gave is actually quite
good: unlike the Haskell version that the other person referred to, it
uses only constant space. And, in my experience, memory management
overhead is significantly less than for similar code in CommonLisp or
C++.

Note also that the GC was deliberately configured to run frequently in
this example so that you can see how much memory is actually used at
various points during the computation.

joe> Is their a transformation system which can prove that
joe> strangesucc x == x + 1 ?

In article <lg3071INN8m1@exodus.Eng.Sun.COM> staffan@chivas.Eng.Sun.COM (Staffan Liljegren) writes:
staffan> So it's not only SML that has these problems. So what are
staffan> some better mechanisms for representing backtracking OR how
staffan> can You circumvent this problem ?

Let's nip this rumor in the bud: SML has no problem with this
construct. Streams are a lazy data structures, and you pay a certain
price for that. Yes, the compiler might be able to figure out in some
cases that it optimize away this loop, but I certainly don't expect it
to in more complex cases.

In general, in a lazy language, you are often at the mercy of the
compiler to prove things about your code in order to obtain decent
performance.  Fortunately, in SML, you have better control over
resources than in a lazy language, so if the Stream data structures
are too inefficient for your purposes (which is actually only rarely
the case), you can choose alternative constructs based on callcc or
tail recursion instead and be more certain about what resource
requirements your program will actually have.

					Thomas.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.functional
Subject: particular example of functional parsing in ML wanted
Date: 7 Nov 92 14:49:11 GMT
Organization: Department of Computer Science, University of Manchester

I mentioned in a previous message that I'd seen a parser which uses
exceptions written in ML i.e. as described in Paulson's book on ML.
However, I was sure that the code I saw was dated 1983 and written by
Robert Harper.  I've checked the ML archive at Edinburgh, but I
couldn't find the code, which leads me to think I've got my wires
crossed and and thinking of Paulson's code.  However I was sure that
the code that I saw used "|||" as the alternation symbol unlike
Paulson.  Does anybody else remember this code?  If so, do you know
where I can get it from?

bevan
Newsgroups: comp.lang.functional
From: bob@giaeb.cc.monash.edu.au (Bob Bignall)
Subject: Knuth/Bendix software
Summary: Looking for software to generate rewrite rules
Keywords: rewrite rules
Organization: Monash University, Melb., Australia.
Date: Fri, 13 Nov 1992 03:18:53 GMT


Can anyone advise me of sources of software which implements
Knuth/Bendix type algorithms for rewrite rule completion?

For example, how might I acquire the Rewrite Rule Laboratory?

Thanks for any assistance.

-- 
Bob Bignall                  Phone :  +61 51 226464     Fax : +61 51 221348
School of Applied Science              Internet: bob@giaeb.cc.monash.edu.au
Monash University College Gippsland
Switchback Road, CHURCHILL 3842, Australia
From: yuen@inagaki.nuie.nagoya-u.ac.jp (Shoji Yuen)
Newsgroups: comp.lang.functional
Subject: SML on RiscOS5.0 with R4000
Date: 10 Nov 92 03:08:08 GMT
Distribution: comp
Organization: Inagaki Lab., Dept. of Info. Eng., Nagoya Univ.

I'm looking for the implementation of Standard ML on
RiscOS5.0 with R4000 cpu.  The binary complied under
RiscOS4.52 works fine on RiscOS5.0 with R3000 cpu.
But with R4000, when I try to "use" a file, it says:

strange floating point error, 3584

(The version of SML I tried is:
     Standard ML of New Jeresey, Version 75, November 11,1991)

Please let me know if there is any site where I can get a
patch or whatever information.

Thank you
(Shoji Yuen: yuen@nuie.nagoya-u.ac.jp)
--
	 ^ ^		$@7k1o(J$@!wL>8E20Bg3X(J.$@>pJs(J.$@0p3@8&(J
	<` '>		yuen@inagaki.nuie.nagoya-u.ac.jp
	  ~
Newsgroups: comp.lang.functional
From: John van Groningen <johnvg@cs.kun.nl>
Subject: Re: Is efficient backtracking feasible in functional languages?
X-Xxmessage-Id: <A7284C6E630120D7@mac1p.cs.kun.nl>
X-Xxdate: Thu, 12 Nov 92 18:01:18 GMT
Organization: University of Nijmegen
X-Useragent: Nuntius v1.1.1d9
Date: Thu, 12 Nov 1992 17:03:44 GMT

In article <1992Nov10.164456.18062@email.tuwien.ac.at> Ulrich Neumerkel
E185/1 +43158801/4477, ulrich@mips.complang.tuwien.ac.at writes:

>strangesucc n =	hd [x|x<-[0..];x>n];
>
>This program should run in constant space and linear time [1].
>However, for the implementations I tried, it turns out that the program
>seems to run in linear space! For a small n as 10000 the program aborts
>due to memory problems. Also a rewriting of the program to encode list 
>comprehensions explicitly did not yield the desired result.

The following rewrite yields the desired result in constant space
in Haskell B:

main = print (h::Integer)

hd (e:l) = e

g n = n : g (n+1)

f [] n = []
f (x:v) n = if (x>n)
               then (x:f v n)
               else (f v n)

h :: Integer
h = hd (f (g 0) 1000000)

But if you change the function 'main' to:

main = print (hd (f (g 0) 1000000)::Integer)

the program runs in linear space !

>Is there ANY implementation of a lazy functional language to execute
>the program above in an efficient manner (i.e. in constant space)?

Yes, Chalmers LML implementation.


                         John van Groningen
Newsgroups: comp.lang.functional
From: wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp)
Subject: Re: Is efficient backtracking feasible in functional languages?
Followup-To: comp.lang.functional
Reply-To: wg@cs.tu-berlin.de
Organization: Technical University of Berlin
Date: Thu, 12 Nov 1992 22:06:21 GMT


>   strangesucc n =	hd [x|x<-[0..];x>n];
>   ...
>   [Major collection... 21% used (3397260/15733684), 1920 msec]
>   ...
>   GC Stack Overflow !

Whats funny with this example that the stream (lazy list) in the list
comprehension can be seen as an imperative counter which is
communicated to the consumer (hd):

    x := 0;
    while (1){
      if (x > n) output(x);
      x++;
    }

We have prototyped a scheme for the compilation of streams which
(nearly) essentially result in such an imperative counter. (Its not
published, but believe, its fairly easy). Its embedded in the approach
of mixed compile-time and run-time garbage collection via the
reference counting model described in [SG91] [Sch92].

It would use constant space for the example, i.e. one cell for the
current "head" of the stream. The head becomes reused if the next
element is demanded by the consument. A stupid straight-forward
compilation would generate a run-time test for the reference counter
of the cell to prove this reusability; a simple sharing analysis would
even eliminate the test at all in the given example (it can easy
detect that their is no context which can share the stream).

Well, we have never implemented the scheme, since streams have been
dropped from the language design we consider ([Pep91]).


@InProceedings{SG92,
  author =      {Wolfram Schulte and Wolfgang Grieskamp},
  title =       {Generating {E}fficient {P}ortable {C}ode for a
                 {S}trict {A}pplicative {L}anguage},
  booktitle =   {Phoenix Seminar and Workshop on Declarative Programming},
  year =        {1992},
  publisher =   {Springer-Verlag}
}

@PhDThesis{Sch92,
  author =      {Wolfram Schulte},
  title =       {Zur {\"U}bersetzung strikter applikativer
                 {P}rogrammiersprachen},
  school =      {Techincal University of Berlin},
  year =        {1992}
}

@TechReport{Pep91a,
  author =      {P. Pepper},
  title =       {The Programming Language OPAL},
  institution = {Technical University of Berlin},
  year =        {1991},
  type =        {},
  number =      {91-04},
  month =       {Apr},
}

--
Wolfgang Grieskamp  
wg@cs.tu-berlin.de 
Newsgroups: comp.lang.functional
From: wand@damon.ccs.northeastern.edu (Mitchell Wand)
Subject: Re: Functional Parsers
Organization: College of Computer Science, Northeastern University
	<BEVAN.92Nov1141304@otter.cs.man.ac.uk>
Date: Fri, 6 Nov 1992 14:59:09 GMT

Seeing the continued interest in functional parsers, I have to mention that
our book contains a chapter on combinator-based parsing, including the
transformation of combinator-based LL parsers into parsing tables and into
recursive-descent parsers.  

It's in Scheme, of course, so it has one or two hacks needed to cope with
applicative-order evaluation (functional-programming purists may pause here to
direct their flames to /dev/null), but is otherwise functional.


The reference is:

Dan Friedman, Mitch Wand, and Chris Haynes, _Essentials of Programming
Languages_, MIT Press, 1992

An updated and improved version of the code can be ftp'd from:

ftp.cs.northeastern.edu:pub/wand/parsers/*

[Also, people should be aware of Michel Mauny's paper on functional parsers,
which was presented at the 1992 ML Conference last June.]

--Mitch 
--
Mitchell Wand
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115     Phone: (617) 437 2072
Internet: wand@flora.ccs.northeastern.edu          Fax:   (617) 437 5121
Newsgroups: comp.lang.functional
From: rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Re: Is efficient backtracking feasible in functional languages?
Originator: rro@CS.ColoState.EDU
Date: Thu, 12 Nov 1992 23:45:28 GMT
Reply-To: rro@cs.ColoState.EDU
Organization: Colorado State University
Keywords: lazy backtracking Gofer


In article <BxM80r.1Hu@dcs.glasgow.ac.uk>, kh@dcs.glasgow.ac.uk (Kevin Hammond) writes:

Stuff deleted.

|> 
|> Most functional language implementations that I know in detail (strict
|> or non-strict) have, or have had, significant space-leak problems.

In our SISAL implementation, finding a space leak was finding a bug,
which got fixed, always.

|> 
|> To reiterate the point, this is an *implementation* issue, NOT a
|> language issue.  For what it's worth, the new Glasgow Haskell compiler
|> has no problem with strangesucc 10000000.  It always "black-holes"
|> entered closures, and should never retain dead values on the stack.
|> 

Agreed that implementors, not language designers, cause these errors.
However, an option that allows faster execution when the user knows
not recovering storage is not going to matter shouldn't be classified
as a space leak.  It's also stupid to recover space when leaving scope
towards program termination.

-- 
|--------------------------------------------------------------|
| Rod Oldehoeft                    Email: rro@cs.colostate.edu |
| Computer Science Department      Voice: 303/491-5792         |
| Colorado State University        Fax:   303/491-6639         |
| Fort Collins, CO  80523                                      |
|--------------------------------------------------------------|
| I pay the price, but do not count the cost.                  |
|                            John Barth, "The Tidewater Tales" |
|--------------------------------------------------------------|
Newsgroups: comp.lang.functional