HDTenEightyP/NetNews huggingface dataset:
From: bromley@think.com (Mark Bromley)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 8 Oct 1992 14:03:37 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: luna.think.com

In article <1992Oct8.124228.10449@kth.se> kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:
>In article <TMB.92Oct7181835@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>
>|> (in fact, not having this
>|> control over evaluation and resources is precisely why I don't like
>|> lazy evaluation).
>
>And it is precisely why I like it. I believe that the "creative" part
>of an algorithm is specifying the data dependencies. Then a good
>compiler should be able to come up with an evaluation order that is at
>least as efficient in terms of resource (eg memory) consumption,
>locality and (when the machine can take advantage of it) parallelism,
>as any I could come up with myself with a reasonable amount of work.

My somewhat uninformed but not completely naive opinion is that this is
expecting way too much from the compiler, and that in fact some level of
control of resources is almost as much a part of the algorithmic process as
specifying data dependencies.  In general there is way too much parallelism
and you have to careful of the order of operations to avoid running out of
memory.  

Note that I am somewhat biased in this matter.  The company I work for has
managed to do quite well by taking almost exactly the opposite point of
view from that expressed above.  I think there is a happy medium somewhere
between the two extremes.

Mark Bromley
Thinking Machines Corp.
Newsgroups: comp.lang.functional
From: esler@apollo.hp.com (Kevin Esler)
Subject: References sought on debugging functional programs
Date: Thu, 8 Oct 1992 21:43:51 GMT
Distribution: comp
Reply-To: esler@apollo.hp.com
Organization: Hewlett-Packard Corporation, Chelmsford, MA

I would like references on debugging of functional programs, including
lazy ones.  I'll post a summary.
--
--  
Kevin Esler //hewlett-packard/cso/nsg/std/clo/mll (MA Language Lab)
esler@apollo.hp.com   (508) 436-5979
Newsgroups: comp.lang.functional
From: richard@harlqn.co.uk (Richard Brooksby)
Subject: Re: Why functional languages?
Organization: Harlequin Limited, Cambridge, England
	<TMB.92Sep28144424@arolla.idiap.ch>
Date: Fri, 16 Oct 1992 18:46:37 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) wrote:

> Too bad that languages like SML (and, moreso, Haskell) have adopted
> such a comparatively complex syntax. Writing programs to manipulate
> programs is much easier in Lisp, due to the obvious correspondence
> between external and internal representation and a standard
> interface to the compiler/type facilities (in the form of macros and
> type predicates).

I'm not sure that languages should encourage such a reflective
approach.  Surely it is better to maintain a clear division between
the `levels' of a compiler system in order to retain semantic
simplicity.  As I see it, it's the semantic simplicity and strong type
enforcement that make developing in a functional programming language
so much more productive.

On a practical note: Introducing reflection of the sort you mention
makes it impossible (or at least difficult) to deliver applications
separate from the compiler.  When your compiler is as complex as a
truly standard ML compiler must be, this is a serious problem.

I agree, however, that the syntax of Standard ML is too complicated.
In fact, it requires infinite lookahead to parse Standard ML (New
Jersey and Poly/ML don't implement it).  This is a shame after so much
effort has gone into the semantics.
---
Richard Brooksby <richard@harlqn.co.uk>
ML Project / Symbolic Processing Division / Harlequin
+44 223 872522
From: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Subject: Re: Why curry? (Re: Why functional languages?)
Reply-To: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 8 Oct 1992 10:02:35 GMT

In article <MFX.92Oct7105619@lenin.cs.tu-berlin.de>, mfx@cs.tu-berlin.de (Markus Freericks) writes:

< Quotes how I implement curried functions in a compiled graph 
  reduction implementation >

|> Your argumentation is based on a graph reduction implementation. I
|> would think that such are only feasible for lazy languages, which SML
|> (which started the thread) is not.

Hmm, that may be right, at least in a language like SML that supports
ref types and :=. Then evaluation order becomes important. What a pain!

< I asked how tuples were optimized in SML >

|> Well, if you have a CPS-based compiler, function call arguments will
|> usually be held in registers, only closures have to be created on the
|> heap (or on the stack, if they provably don't escape). And in such an
|> environment, tupling is much cheaper! (Again, it is of course true
|> that a very naive approach would allocate tuples as data objects on
|> the heap.)

It seems that everybody knows the tricks needed to implement the 
idioms that are common in their language of choice, and tacitly
assumes that these tricks have been used, at the same time expecting
all other languages/idioms to have been implemented naively. 

< Discussion of type signatures >

|> Well, in my SML programs (I am writing a partial evalutor) i tend to
|> have functions of 4-5 parameters, and missing parameters are one of
|> the most typical typing errors I make. Of course, type check would
|> catch most of these in a currying language, too. 

In fact, the type checker catches all of these errors in either case,
but I grant that the error messages probably will be somewhat more
informative for tupling errors (e.g. 'Unable to unify ('t2133 * 't2150)
with ('t2133 * 't2133 * 't2165)' vs. 'Unable to unify (Char) with 
('t2133 -> 't2156)).

|> Well, for me the question is: does a language *force* me to use
|> curried functions, or does it offer tupled functions, too? For me,
|> tupling is a safety device, a little comparable to typing, that makes
|> it possible to say "this function should be called with so many
|> arguments". A language that does not support this device (or makes it
|> overtly expensive, e.g. by explicitly creating/desctructing tupel
|> objects) lacks a feature that makes life easier.

So, the conclusion is: provide and optimize both tupling and currying!
Your wish is my command :-)

Cheers,
         Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!
Newsgroups: comp.lang.functional
From: gupta@nmsu.edu (Gopal Gupta)
Subject: Logic Programming as an Introductory Programming Paradigm
Organization: NMSU Computer Science
Date: Mon, 12 Oct 1992 16:09:29 GMT


		   Second Call for Participation

		Logic Programming as an Introductory
			Programming Paradigm

		Informal Birds-of-a-Feather Session
		
		Joint International Conference and 
		Symposium on Logic Programming '92

		      Tuesday, Nov 10th, 1992
			   6:00PM -- 8:30PM

		  Organizers: J. Reinfelds and G. Gupta

This informal session is  devoted to  discussion on  using  the  logic 
programming  paradigm to teach programming to beginners. The  emphasis 
is on  teaching  logic  programming (rather than Prolog), and  the aim 
is to induce beginners to learn ``declarative thinking." This approach 
can be  contrasted with  the functional programming  approach that has 
been becoming increasingly popular recently.

The discussion  is open to  all the participants in the conference who 
are  invited  to present  their  views on  (but  not  limited  to) the 
following issues:

1) Why is  Logic  Programming  a  more  suitable paradigm for teaching 
	programming to beginners?
2) Is there a need for  using LP for this purpose, or is FP enough, or
	is some other approach better?
3) How to evaluate the success of such an enterprise?
4) Your  experiences  related  to  using  LP  to  teach programming to
	beginners.

Dissenting views are specially welcome.  

As part of the session  we will  relate our  experience  with using LP 
(and a closely co-ordinated  sister course in discrete Math and Logic) 
to teach programming to Freshman students  at New Mexico State. Others 
are welcome to relate their experiences too. 

Please note  that the primary focus of the session will be on teaching 
logic programming to beginner programmers. Discussion related to teach-
ing Logic Programming to people other than beginners is not encouraged.

Please  send email (to gupta@nmsu.edu  or  juris@nmsu.edu) if  you are 
interested in participating. Please indicate in your email if you just 
want to attend the session or  whether you  intend to  present a short 
position paper too. Those who have already expressed interest need not
do so again.


---------------------------------------------------------------------
Gopal Gupta
Department of Computer Science	   email: gupta@nmsu.edu
Box 30001, Dept. 3CU		      	  gupta@compsci.bristol.ac.uk
New Mexico State University	   Ph: +1 (505) 646 6236 
Las Cruces, NM 88003-0001	   Fax: +1 (505) 646 6218
USA
---------------------------------------------------------------------

	 
Newsgroups: comp.lang.functional
From: joe@erix.ericsson.se (Joe Armstrong)
Subject: Machine readable text of Bird & Wadler??
Nntp-Posting-User: joe
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Mon, 12 Oct 1992 09:30:47 GMT

	Does anybody know if the programs in Bird and Wadler are available in
a machine readable (ftp'able) form? - preferrably converted to gofer.

	Thanks
From: brown@pollux.cs.uga.edu (Daniel Brown)
Newsgroups: comp.lang.functional
Subject: Need Miranda compiler
Date: 12 Oct 92 18:49:42 GMT
Organization: University of Georgia, Athens
Originator: brown@pollux

Where can I find a Miranda compiler for a DOS or Unix environment?  Please
reply via e-mail.

-- 
Daniel W. Brown (brown@pollux.cs.uga.edu)
Newsgroups: comp.lang.functional,comp.software-eng
From: cs3ea3cd@maccs.dcss.mcmaster.ca (Abrams       J)
Subject: Looking for recent paper on SML/Software Eng. Topic
Organization: Department of Computer Science, McMaster University
Date: Fri, 16 Oct 1992 18:24:02 GMT

I am looking for a recent paper to review which should be on a software
engineering topic and be involved with the SML language.

Any help would be appreciated.


-- 
Jonathan H. Abrams - McMaster University, Canada 

cs3ea3cd@maccs.dcss.mcmcaster.ca
Newsgroups: comp.lang.functional
From: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Subject: Re: SML Pretty-printing
Reply-To: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Wed, 7 Oct 1992 11:23:26 GMT

In article <91849@netnews.upenn.edu>, freeman@linc.cis.upenn.edu (Jon Freeman) writes:
|> Regarding SML, kff@dentex.tds.kth.se (Karl-Filip Faxen) says:
|> 
|> >|> and it seems to be difficult to indent automatically as well.
|> >
|> >In an Emacs mode, perhaps. In a pretty printer, certainly not (I've
|> >written one).
|> >
|> >Cheers,
|> >         Karl-Filip
|> 
|> I never even thought that writing a pretty-printer for SML was a
|> feasible undertaking.  Consider the following program:

OOPS! I was comparing pretty-printing curried application and
applications involving tuples. I didn't say I'd written a 
pretty-printer for SML (I haven't; it's for a subset of Haskell).

|> --------------------------------------------------------------
|> datatype foo = Alpha of int | Beta of real | Gamma of string;
|> datatype bar = Happy of int | Dopey of real | Grumpy of string;
|> 
|> fun testcase (x,y) =
|>   case x of
|>     Alpha _ => ()
|>   | Beta _ =>
|>       case y of
|>         Happy _ => ()
|>       | Dopey _ => ()
|>       | Grumpy _ => ()
|>   | Gamma _ => ();       (* Hmmm... *)
|> --------------------------------------------------------------
|> 
|> Any pretty-printer that can correctly indent the last line of testcase
|> has to be able to discriminate between the constructors of foo and the
|> constructors of bar!!  Does your pretty-printer really do this?  If
|> so, I'm very impressed.

This isn't a problem of pretty-printing, it's a problem of parsing!
Actually, for your example to be syntactically correct, you have 
to have either a layout dependent syntax or (which I understand you 
to mean) a context dependent syntax. That would be really wierd for
a modern programming language! Given, however, that the parsing 
problem is solved and I have an abstract syntax tree, it wouldn't 
be _that_ difficult to produce this layout (it wouldn't be difficult 
at all if you produced something that was parsable with a context-
independent parser).

Cheers,
          Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: Resource control (was: Re: Why curry?)
Date: 13 Oct 92 01:05:48 GMT
	<TMB.92Oct10173521@arolla.idiap.ch> <1992Oct12.150018.14053@kth.se>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: kff@dentex.tds.kth.se's message of 12 Oct 92 15:00:18 GMT

In article <1992Oct12.150018.14053@kth.se> kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:

   (1) A compiler has no knowledge about input data (except for their
       type). If the programmer has this knowledge, it can be communicated
       to the compiler using annotations, or can be studied with profiling.
       This of course requires access to "typical input", a somewhat shakey
       notion, but no less shakey than the programmers intuition. Also,
       the compiler could generate code for run-time scheduling in some 
       cases.

Actually, I think ultimately, this should go much further: code should
be compiled and optimized _on the fly_. There shouldn't be a division
into "compilation, profiling, optimizing, execution". Some Smalltalk
systems already do this, both in the form of byte-code->native-code
compilation for heavily used routines and in the form of backpatching.
I have done a little work on optimizing runtime type checking in
CommonLisp by gathering statistics and compiling code on the fly, but
the applications clearly go much further.

   |>    It may be that annotations are a good idea, separating data dependencies
   |>    from resource management decisions.
   |> 
   |> Well, yes. And taking advantage of eager evaluation for these kinds of
   |> "annotations" seems to be quite natural. Why change this?

   Here, I'm afraid I don't understand what you want to say. Could you please
   rephrase it? 

What I'm saying is that most people who know SML reasonably well
understand clearly how I want my computation to be carried out when I
write something like:

   fun f(x) =
       let
   	   val z = g(x)
       in
           fn y => h(y,z)
       end
   
   fun f'(x) = fn y => h(y,g(x))

In the first case, I don't want "g(x)" to be recomputed, in the second
case I do want it recomputed. It seems that this is annotation enough.
Why invent a new notation? (In those cases where you don't care, you
can simply choose one or the other, and even a compiler for an eager
purely functional language can often legally transform one version
into the other.)

					Thomas.
From: HEDDEN@ESDSDF.dnet.ge.com (Jerry D. Hedden)
Newsgroups: comp.lang.functional
Subject: Computer Algebra in ML
Date: 15 Oct 1992 08:58:55 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

I am interested in exploring the development of a
computer algebra system using ML (CAML-Light actually).
The specific application will deal with tensors.

Has anyone done any work in this area?
Is there source code, grammars, etc. available?
Any literature on the subject?

Thank you,
Jerry D. Hedden
hedden@esdsdf.dnet.ge.com
Newsgroups: comp.lang.functional
From: dhw@plex-1.ann-arbor.mi.us (David West)
Subject: Re: Resource control (was: Re: Why curry?)
Organization: Plex-1, Michigan's Public Access Usenet Gateway  (Ann Arbor).
Date: Thu, 15 Oct 1992 18:02:11 GMT

In article <TMB.92Oct14195941@arolla.idiap.ch> tmb@idiap.ch writes:
>You might say: "well, we only cache intermediate results like 'g(x)',
>but if we run out of memory, we flush them". The problem is that that
>will most likely also flush the few precious intermediate results that
>I know I want to keep.

So perhaps a good policy would be to flush cached results in (approximately)
increasing order of "time density".

-- 
-David West            dhw@plex-1.ann-arbor.mi.us

"Ce n'e'tait pas un empire comme il faut, mais nous nous sommes diablement
bien amuse's."  -Col. Fleury, aide-de-camp of Napoleon III
From: george@allegra.att.com (Lal George)
Newsgroups: comp.lang.functional
Subject: Re: I want sml/NJ on IBM RS/6000.
Date: 15 Oct 92 15:55:32 GMT
Followup-To: comp.lang.functional
Distribution: comp
Organization: AT&T Bell Laboratories

SML/NJ has been up and running on the RS6000 for over 2 months 
now. The next public/official release to be announced, will 
contain the port.

Some preliminary numbers indicate that a 25MHz, Model 32H, RS6000 
with 32 Mbytes of memory is about 33-66% faster than my 40MHz, 
Sparc II workstation with 64 Mbytes of memory.

The announcement of the next release will be posted on this 
newsgroup.
Newsgroups: comp.lang.functional,aus.jobs
From: joswig@informatik.uni-hamburg.de (Rainer Joswig)
Subject: Re: Why functional languages?
Followup-To: comp.lang.functional
Organization: University of Hamburg, FRG
Date: Wed, 7 Oct 92 13:42:46 GMT

In article <26463@castle.ed.ac.uk>, jamesh@castle.ed.ac.uk (James
Hammerton) wrote:
> Nor to me, but I think that it is a bad example to use anyway. So lets
> try something to show the readability a bit better.  Consider the
> factorial function. In scheme it would be:
> 
> (define fac
>  (lambda (n)
>   ( if (= 0 n)
>     1
>     (* n (fac (- n 1))))))
> 
> Is that enough brackets?! ;-)
> 
> In SML:
> 
> fun fac 0 = 1		   [ or  fun fac n = if n=0 then 1 else n*fac(n-1); ]
> |   fac n = n * fac (n-1) ;
> 

Well, you are comparing apple and oranges :-).

Your Lisp example doesn't use pattern matching.

There are macros for lisp (like the SELECT-MATCH macro for
Common Lisp) which will implement SML style pattern matching.
The your lisp code will look very different.


Rainer Joswig
Email: joswig@informatik.uni-hamburg.de
From: bruns@dcs.ed.ac.uk (Glenn Bruns)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 9 Oct 92 11:31:44 GMT
Organization: Department of Computer Science, University of Edinburgh

I'm not clear about what I should conclude about New Jersey ML from
this thread.  Will the use of tupled function definitions in
NJML generally result in better efficiency?

-- 
Glenn Bruns
Laboratory for Foundations of Computer Science
University of Edinburgh
Newsgroups: comp.lang.functional
From: sra@ecs.soton.ac.uk (Stephen Adams)
Newsgroups: comp.lang.functional
Subject: Re: SML Pretty-printing
Date: 8 Oct 92 08:05:33 GMT
Organization: Southampton University Computer Science
In-reply-to: freeman@linc.cis.upenn.edu's message of 6 Oct 92 16:20:53 GMT

In article <91849@netnews.upenn.edu> freeman@linc.cis.upenn.edu (Jon Freeman) writes:

 > Regarding SML, kff@dentex.tds.kth.se (Karl-Filip Faxen) says:
 > 
 > >|> and it seems to be difficult to indent automatically as well.
 > >
 > >In an Emacs mode, perhaps. In a pretty printer, certainly not (I've
 > >written one).
 > >
 > >Cheers,
 > >         Karl-Filip
 > 
 > I never even thought that writing a pretty-printer for SML was a
 > feasible undertaking.  Consider the following program:
 > 
 > --------------------------------------------------------------
 > datatype foo = Alpha of int | Beta of real | Gamma of string;
 > datatype bar = Happy of int | Dopey of real | Grumpy of string;
 > 
 > fun testcase (x,y) =
 >   case x of
 >     Alpha _ => ()
 >   | Beta _ =>
 >       case y of
 >         Happy _ => ()
 >       | Dopey _ => ()
 >       | Grumpy _ => ()
 >   | Gamma _ => ();       (* Hmmm... *)
 > --------------------------------------------------------------
 > 
 > Any pretty-printer that can correctly indent the last line of testcase
 > has to be able to discriminate between the constructors of foo and the
 > constructors of bar!!  Does your pretty-printer really do this?  If
 > so, I'm very impressed.

Is this legal?  NJ/SML gives me a type error. Whether the
Gamma choice belongs to case x or case y is purely a matter
of syntax, and so I would hope that the pretty printer gets
it `wrong', otherwise it would be misleading!  To get what
you want you have to put the case y in parentheses of a `let
in ... end'

	- fun testcase (x,y) =
	=   case x of
	=     Alpha _ => ()
	=   | Beta _ =>
	=       case y of
	=         Happy _ => ()
	=       | Dopey _ => ()
	=       | Grumpy _ => ()
	=   | Gamma _ => ();   
	std_in:8.7-12.17 Error: rules don't agree (tycon mismatch)
	  expected: bar -> unit
	  found:    foo -> unit
	  rule:
	    Gamma _ => ()
	- 

I find that the Emacs SML mode by Lars Bo Nielsen
(lbn@iesd.auc.dk) adequate (I use version 2.5, this might
now be antique, the file has creation date 1989).
Occasionally it does things that I don't like but I am
prepared to correct them manually (or as often just accept
them).
--
Stephen Adams                           Email: S.R.Adams@ecs.soton.ac.uk
Electronics and Computer Science        Tel: 0703 593649
University of Southampton               Fax: 0703 593045 
Southampton  SO9 5NH,  UK
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: SML Pretty-printing
Date: 7 Oct 92 22:31:20 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: freeman@linc.cis.upenn.edu's message of 6 Oct 92 16:20:53 GMT

In article <91849@netnews.upenn.edu> freeman@linc.cis.upenn.edu (Jon Freeman) writes:

   I never even thought that writing a pretty-printer for SML was a
   feasible undertaking.  Consider the following program: [...]


Well, Jon's example didn't work, but what about the following:
the interpretation of a curried call like

	f 3 foo 4

depends on whether "foo" is an "infix" operator (e.g., "before") or
not. This may perhaps not affect indentation, but it may trip up other
tools.

					Thomas.

PS: the "problem" goes away if you require all arguments to be
parenthesized, like other languages do (or, at least, adopt this as a
convention):

	f(3)(foo)(4)

is unambiguous.
Newsgroups: comp.lang.modula2
From: chip@ac.dal.ca
Newsgroups: comp.lang.modula2
Subject: FST 3.0 DOS and LZEXE
Date: 10 Oct 92 23:20:01 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

Hello,

  I just got a copy of FST Modula-2 (3.0).  I compiled the sample program,
  using all the defaults.  When I tried to compress the EXE with LZEXE,
  it compressed but when I re-ran the file it locked up my system.

Is there any reason why the shareware version of FST M2 wouldn't let
me use an EXE compressor on my compiled code?

Thanks....Mark Klaamas
Newsgroups: comp.lang.modula2
From: randy@psg.com (Randy Bush)
Subject: FST 3.0 available - .DEF timestamps fixed
Organization: Pacific Systems Group, Portland Oregon, US
Date: Fri, 9 Oct 1992 13:42:16 GMT

Roger and Pat helped me fix the timestamp problem with the \LIB\*.DEF
files.  So, a new version is now available as

    ftp.psg.com:~/pub/modula-2/pc/fst30a.lzh

    -rw-rw-r--   1 randy    news         199 Oct  9 06:35 Index
    -rw-rw-r--   1 randy    news      306102 Oct  9 06:34 fst30a.lzh

Note the 'a' suffix.  Note that this is also available on FidoNet from
node 1:105/6 (V.32bis).

Pat says that there are some small blemishes internal to the compiler and
library which he hopes that Roger will fix in a follow-on release in some
weeks.  So I suggest you beat this one to death and get all possible bug
reports in soonish.

Many many thanks to Roger for this net.good.deed.

randy
-- 
randy@psg.com   ...!uunet!m2xenix!randy