HDTenEightyP/NetNews huggingface dataset:
From: S.Courtenage@cs.ucl.ac.uk (S.A. Courtenage)
Newsgroups: comp.lang.functional
Subject: Re: Linear types (was Re: Unique types etc.)
Date: 5 Oct 92 09:00:15 GMT


 >>Unique types seem related, if not identical, to what Phil Wadler
 >>calls "linear types". His (and others) work is (as far as I know)
 >>based on Girard's linear logic, in which assumptions must be used
 >>exactly once. Thus the type checker guarantees that variables with
 >>linear types are used exactly once. 
 >
 >Which brings up the question... if linear logic insists that assumptions be
 >used exactly once, does a language with linear types insist that linear
 >variables be used exactly, as opposed to at most, once? What breaks if you
 >just insist that variables with "linear" types be used at most
 >once---"single threading"? (Is it some sort of strictness that breaks?)
 >
 >Jeremy (a linear novice)

The philosophy behind the development of Linear logic concerns control over
the use of resources. A resource, e.g. an argument to a function, can be used
0, 1 or many times. Only if we restrict its use to exactly once do we achieve
explicit control over its use such that, e.g. we can automatically reclaim the
resource when it is finished with. Relaxing the notion of "linearity" to at
most once means that this control is lost as much as if we had no linearity
at all. The idea proposed above is more akin to "sticky" reference counting.

Simon Courtenage		Email: scourten@uk.ac.ucl.cs
Dept of Computer Science
University College London
London WC1E
England
Newsgroups: comp.lang.functional
From: brian@comp.vuw.ac.nz (Brian Boutel)
Subject: Re: SML Pretty-printing
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Date: Tue, 6 Oct 1992 20:49:51 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:
|> 
|> --------------------------------------------------------------
|> 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.

That would be clever, but doesn't the definition say that matches extend as far
to the right as possible? In this example, the last line would be parsed as part
of the inner case expression, and the program contains a type error.

--brian

-- 
Internet: brian@comp.vuw.ac.nz
Postal: Brian Boutel, Computer Science Dept, Victoria University of Wellington,
        PO Box 600, Wellington, New Zealand
Phone: +64 4 471-5328   Fax: +64 4 495-5232
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 4 Oct 92 20:13:31 GMT
Article-I.D.: alice.23795
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <TMB.92Oct4181821@arolla.idiap.ch> tmb@idiap.ch writes:

> Why _do_ people continue to use curried syntax when they just want a
> function with several arguments?

Perhaps because it makes partial application easier to write.

For example, if I want a vector whose elements are twice the corresponding
elements of x, I can write

	map (fn x => x * 2) x

or, if I have a curried multiply function, I can write

	map (mult 2) x

I suppose I might ask the complementary question: why should compilers
generate slower code for curried functions if I don't happen to make
use of that property?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.functional
From: tyan@cs.cornell.edu (Thomas Yan)
Subject: Re: concrete vs abstract syntax or syntax trees
Organization: Cornell University, CS Dept., Ithaca, NY
Date: Wed, 30 Sep 1992 17:58:41 GMT

In article <TMB.92Sep29100759@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> In article <DBM.92Sep28220940@ai.allegra.att.com> dbm@allegra.att.com (Dave MacQueen) writes:
|> 
|>    Actually, I would prefer to move further away from Lisp style syntax.
|>    One of the unfortunate aspects of SML syntax is the overloading and
|>    consequent over-use of parentheses.  Parentheses play three main
|>    roles:
|> 
|>     (1) grouping (this is the most fundamental role)
|> 
|>     (2) bracketing tuples as in (1, true, "abc")
|> 
|>     (3) bracketing sequence expressions, as in (print "a"; print "b")
|> 
|> 
|> Well, I'm not so sure I agree. I think (3) should not matter, since
|> imperative programming is the exception, not the rule in SML (right?).

well, what about the example given, namely printing (and more generally
using input/output streams)?  this is even more true in concurrent ml,
in which communication between threads is done on channels.  

|> And I don't see much of a conflict between (1) and (2); in particular,
|> I like the fact that function calls with tupled arguments look
|> "normal" ("f(x,y,z)") right now.

i guess i might be missing the point here.  by (1), i thought this 
referred to expressions like f(g(h(k x))) having tons of parens, vs.
f g h k x, which has none.  i don't see how this relates to your
comments.

- thomas
From: alti@dcs.ed.ac.uk (Thorsten Altenkirch)
Newsgroups: comp.lang.functional
Subject: Re: 3rd order functions
Date: 2 Oct 92 12:34:50 GMT
	<1992Oct1.174259@cs.utwente.nl>
Organization: LFCS, Edinburgh

In article <1992Oct1.174259@cs.utwente.nl> ramaer@cs.utwente.nl (Mark Ramaer) writes:

   "alt" chooses between two "a"-parsers.

   > alt :: ([t]->Bool) -> Parser t r a -> Parser t r a -> Parser t r a
   > alt test aa bb = \contin input ->
   >       if test input
   >	then aa contin input
   >       else bb contin input

   > sequenceOption :: ([*]->bool) -> Parser t r a -> Parser t r [a]
   > sequenceOption test aa = alt test (sequence test aa) (empty [])

   "Parser t r a" is a 2nd order type, so "alt" and "sequenceOption"
   are 3rd order functions.

Thanks Mark, this certainly is a 3rd order function. In another
posting I tried to make the requirements more precise:

   If we have polymorphism, it is not clear what level to assign to type
   variables. In fact it is quite easy to get a 3rd order functions just
   by instantiating the type of polymorphic map by a 1st order function
   type for the input list. However, I am interested in *genuine* higher
   order functions, i.e. which do not show up as instantiations of
   polymorphic functions. This means that in this context I consider the
   order of a type variable as 0.

Your function alt can be obtained by instantiating a 2nd order
polymorphic function to the type Parser, right? In this way it is not
genuinely higher order.

The following is an example of a genuine higher order function, but
alas it is not very interesting (it is just an instance of
application): 

	\lambda: f:((N->N)->N)->N.f succ
	: ((N->N)->N)->N

--
Thorsten Altenkirch		LFCS, Edinburgh

"Germany still proves reluctant to exchange email with other countries 
efficiently" - Summer 1992 Systems Newsletter, Dep. of CS,Edinburgh
Newsgroups: comp.lang.functional
From: peterson-john@CS.Yale.Edu (John C. Peterson)
Subject: New release of Yale Haskell now available
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Distribution: comp
Date: Fri, 2 Oct 1992 13:33:02 GMT


      Announcing the beta 2 release of Yale Haskell 2.0

The updated version of the Yale Haskell compiler beta release is now
available.  We have fixed many of the problems in the original beta
release and significantly improved performance.  We also have ported the
system to akcl.  The documentation and tutorial have also been improved.

Except for a few I/O requests not applicable to our interactive
environment, we now implement the full Haskell as defined in the 1.2
report.

We are releasing two versions of the system: an executable compiled
with the CMU Common Lisp system which runs on Sparc systems and a full
source release which will build on Lucid common lisp, CMU common lisp,
and akcl.  The build process consumes a large amount of virtual memory -
you may have some difficulty using the source release.  If you cannot
use either of these versions, please wait for the next release.

Our system is available for anonymous ftp at all three Haskell ftp sites:

        Site     Host name              Raw IP address

        Chalmers animal.cs.chalmers.se  129.16.225.66
        Glasgow  ftp.dcs.glasgow.ac.uk  130.209.240.50
        Yale     nebula.cs.yale.edu     128.36.13.1

The files are in the directory pub/haskell/yale.

Two files are available:
haskell-beta-2-source.tar.Z   -- full sources
haskell-beta-2-sparc.tar.Z    -- sparc executable

(Note: if anyone wants to contribute a pre-compiled system using the cmu
compiler for non-sparc machines please let us know.  We are not authorized
distribute precompiled akcl versions of our compiler.)

You should only need one of these files.  The sources take a few hours
to build.  The executable is ready to run immediately.

To obtain Yale Haskell via ftp:

  - Move to the directory where you intend to place Yale Haskell
  - Ftp to one of the sites and login anonymously
  - Get the tar file: get xxx.tar.Z   where xxx is the distribution you want
  - cd to pub/haskell/yale
  - Uncompress and untar the file on your machine:
           uncompress haskell-*.tar.Z
	   tar xf haskell-*.tar
  - Consult the documentation for further instructions.  Either print
    out the reference manual in doc/manual/haskell.dvi or look at
    install.verb in the same directory.


Send any comments or questions to haskell-request@cs.yale.edu
From: dlb@fanny.wash.inmet.com (David Barton)
Subject: Re: 3rd order functions
Organization: Intermetrics Inc., Washington Division, USA
Date: Thu, 1 Oct 1992 14:46:42 GMT

In article <BvFvEz.7A@dcs.ed.ac.uk> alti@dcs.ed.ac.uk (Thorsten Altenkirch) writes:

   However, I find it quite hard to come up with useful examples of 3rd
   order functions (e.g. which have types like ((A->B)->C)->D).

   Sure, it is not hard to come up with constructed examples like:

	   \lambda f:(A->A)->B . f (\lambda  x:A . x) : ((A->A)->B)->B

   but I am rather looking for examples motivated by programming
   problems. 

   Any ideas?

Check out microwave and analog engineering.  Information is passed as
"signals", or functions from time (or frequency) to some other
physical quantity, such as voltage, current, or power.  The function
of various devices is expressed as a function on these signals; for
example, in the simple case, a mixer will take two functions and
produce a function which is their sum.

As this gets more complex (for example, writing a general description
which produces behaviors based upon parameters such as gain and power
consumption), third order functions appear frequently.

					Dave Barton
					dlb@hudson.wash.inmet.com
From: dsc@sys.uea.ac.uk (Dave Cartwright CMP)
Newsgroups: comp.lang.functional,uk.jobs
Subject: Applications for RA Post Invited
Date: 29 Sep 92 08:12:50 GMT
Organization: UEA School of Information Systems, Norwich, UK.


                                            School of Information Systems
						UEA, Norwich

Multi-Paradigm Programming through Graph Rewriting

Senior Research Associate in Computer Science

Applications are invited for a postdoctoral Research Associate to work
on the UK SERC funded project "Multi-Paradigm Programming through Graph
Rewriting" with Dr John Glauert. Graph rewriting underlies many
practical functional programming language implementations. It has also
been shown that extended graph rewriting can implement features of logic
and concurrent programming languages. The project aims to demonstrate
that graph rewriting notions can form the basis for practical
implementations of languages combining these paradigms. The primary
objective is to develop efficient techniques for sequential
architectures, but a further aim of the project is to experiment with
techniques for parallel implementation .

The Research Associateship is available for a period of up to three
years commencing 1 December 1992. Salary will be on the RA(1A) scale
UKL12,129 to UKL17,827 per annum (under review). Applicants should have
or be very close to gaining a PhD degree. Experience in compiling
techniques, declarative programming languages, or concurrency theory
will be an advantage.

Applications, naming two referees, should be sent to Dr JRW Glauert,
School of Information Systems, University of East Anglia,
Norwich NR4 7TJ, from whom further particulars may be obtained
(email jrwg@sys.uea.ac.uk, tel +44 603 592671, fax +44 603 507720).
The closing date is 16th October 1992.

UEA is an Equal Opportunity Employer
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.functional
Subject: Re: Why functional languages?
Date: 5 Oct 92 23:43:56 GMT
	<26463@castle.ed.ac.uk> <1992Oct2.053333.20373@daffy.cs.wisc.edu>
	<farrell.718241256@coral>
Organization: Department of Computer Science, University of Manchester
In-reply-to: farrell@coral.cs.jcu.edu.au's message of 4 Oct 92 23:27:36 GMT

In article <farrell.718241256@coral> farrell@coral.cs.jcu.edu.au (John Farrell) writes:
     It seems to me that a syntax error in Lisp is very hard to make,
     as so long as you have the right number of brackets, everything
     is a valid program.  

Even if you take "valid" to mean the very weak guarantee that a
program is "syntactically correct" the above statement is still wrong.

To prove this, try typing random things with the "right number of
brackets" into a Lisp system with a compiler and watch it kick out all
manner of errors about the input.

bevan
From: nickh@CS.CMU.EDU (Nick Haines)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 5 Oct 92 21:09:04 GMT
Article-I.D.: VOILA.NICKH.92Oct5160904
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
	<BvGz2u.2rv.1@cs.cmu.edu> <NICKH.92Oct2134230@VOILA.VENARI.CS.CMU.EDU>
	<TMB.92Oct4181821@arolla.idiap.ch>
	<CARLTON.92Oct5110856@sc
Organization: School of Computer Science, Carnegie Mellon University
Originator: nickh@VOILA.VENARI.CS.CMU.EDU

In article <CARLTON.92Oct5110856@scws8.harvard.edu> carlton@scws8.harvard.edu (david carlton) writes:

   Why does SML support functions of multiple arguments using both tuples
   and curried functions, anyways?

1. All functions in SML take one argument. Thinking of "functions of
multiple arguments" results in confusion of the sort you show in your
questions.

2. SML supports curried functions because in some contexts they are
	nice to use.

3. Tuples in SML are merely glossed-over record types:
	(42,true,"foo")     = {1 = 42, 2 = true, 3 = "foo"}
	int * bool * string = {1 : int, 2 : bool, 3 : string}
   ("1", "2", and "3" on the RHS are labels for record elements)

   [...]. And how much of a problem is it in practice?

None at all in my experience.

   [...] Also, what sorts of order-of-evaluation constraints does SML
   impose?  If you are compiling "f g h", say, and the compiler can't
   prove that evaluating "f g" won't have side effects, does it have
   to evaluate "f g" before evaluating "h"?  And is it required to
   evaluate "f" before "g"?

Yes to both questions, for a single reason, rules 112-118 in the
Definition require that in function applications, the function should
be evaluated before the argument. This applies to the "f g h"
question, because this is an application of the function value "f g"
to the argument "h".

Nick Haines nickh@cmu.edu
Newsgroups: comp.lang.functional
From: leonp@cs.kun.nl (Leon Pillich)
Subject: Re: Unique types etc.
Organization: University of Nijmegen, The Netherlands
Date: Sat, 3 Oct 1992 17:24:03 GMT

In <1992Oct2.170149.24827@plex-1.ann-arbor.mi.us> dhw@plex-1.ann-arbor.mi.us (David West) writes:

>In article <BvG3I3.B2M@sci.kun.nl> leonp@cs.kun.nl (Leon Pillich) writes:
>>We should rewrite G as:
>>:: G Clock -> ....
>>   G clock -> ..... time1 ..... time2,
>>              (clock', time1): GetTime clock,
>>              (clock'', time2): GetTime clock';
>>
>>We now have time1 and time2 with the correct values, yet it remains
>>referentially transparent and therefore functional.

>Don't you need to somehow make clock'' available for the next invocation
>of GetTime anywhere, even within G?  Or have I misunderstood how this is
>supposed to work?

Sure, but only whenever you will need it again. 
But indeed normally you would write such programs like
- first initialize a unq type i.e. Open a UNQ file, clock etc
- a cascade of functions each having the unq type as input
  and the again as output
- when thers no need anymore of the type just discard it

Thats all to it....


Leon Pillich
University of Nijmegen, Holland
email: leonp@cs.kun.nl
-------------------------------------------------------------
 Life is what's happening when you're making other plans ...
                                      John Lennon
From: alti@dcs.ed.ac.uk (Thorsten Altenkirch)
Newsgroups: comp.lang.functional
Subject: 3rd order functions
Date: 1 Oct 92 10:49:47 GMT
Organization: Department of Computer Science, Edinburgh University

Second order functions are used quite frequently in functional
programming - examples are:

	map: (A->B)->LA->LB
	sort: (A->A->Bool)->LA->LA

However, I find it quite hard to come up with useful examples of 3rd
order functions (e.g. which have types like ((A->B)->C)->D).

Sure, it is not hard to come up with constructed examples like:

	\lambda f:(A->A)->B . f (\lambda  x:A . x) : ((A->A)->B)->B

but I am rather looking for examples motivated by programming
problems. 

Any ideas?

--
Thorsten Altenkirch		LFCS, Edinburgh

"Germany still proves reluctant to exchange email with other countries 
efficiently" - Summer 1992 Systems Newsletter, Dep. of CS,Edinburgh
From: dirkd@cs.kuleuven.ac.be (Dirk Dussart)
Newsgroups: comp.lang.functional
Subject: Plotkin Lectures ???
Date: 6 Oct 92 14:23:25 GMT
Organization: Dept. Computerwetenschappen

Hi Netlanders,

Is there anybody who knows where I can find the following article or
paper of Plotkin : Post-graduate lecture notes in advanced Domain Theory
(incorporating the Pisa-notes) Dept. of Computer Science, Univ. of Edinburgh 
1981 
in computer readable form (TeX or Postscript or Troff ,....).  

Dirk Dussart.

P.S. Thanks in advance.
     
Newsgroups: comp.lang.functional
From: dbarker@spang.Camosun.BC.CA (Deryk Barker)
Subject: Re: Type checking with physical dimensions
Organization: Camosun College, Victoria B.C, Canada
Date: Mon, 28 Sep 1992 19:22:53 GMT

In article <DLB.92Sep28100432@fanny.wash.inmet.com> dlb@fanny.wash.inmet.com (David Barton) writes:
>I was going to respond to this by Email; however, since it might be of
>general interest, I am responding to the list.
>
>In article <14724@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au
>(Richard A. O'Keefe) writes:
>
>   Has anyone extended a Hindley/Milner-style type checker to check
>   physical dimensions (mass,length,time,current,&c)?  I have my own ideas
>   about how to do it, but before I start coding and writing, I'd like to
>   know what has already been done.  (I already know that it is possible to
>   combine polymorphism with dimension checking; I _think_ I can see a way
>   to combine them with integer/float overloading; I believe that automatic
>   scaling can be done in a functional language but not in a logic programming
>   language, but don't ask me to prove it yet.)
>
>We are desigining a microwave hardware description language based upon
>Haskell.

All this just to cook food? (Sorry, I couldn't resist it!)

Deryk Barker, Computer Science Dept., Camosun College, Victoria B.C.
Newsgroups: comp.lang.functional
From: clin@eng.umd.edu (Charles Lin)
Subject: Why functional languages?
Date: Sat, 26 Sep 92 21:29:35 GMT
Organization: College of Engineering, University of Maryland, College Park
Originator: clin@harmonic.eng.umd.edu


   Well, a while back, I asked people why functional languages were useful,
interesting, etc.   I have two followup questions, and unfortunately
I was a little lazy and didn't type the correct sunject heading, which
should have been "Why are you interested in functional languages?".

   So, I'm interested in why you wanted to do work in this area, and
also what you think the important kinds of questions or work will
be done in the area, either now, or in the future.

   E-mail or post.

--
Charles Lin
clin@eng.umd.edu
Newsgroups: comp.lang.functional
Subject: Re: Why functional languages?
From: brian@comp.vuw.ac.nz (Brian Boutel)
Date: Fri, 2 Oct 1992 08:14:59 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.


In article <farrell.718005712@coral>, farrell@coral.cs.jcu.edu.au (John Farrell) writes:
|> In <BvGz2u.2rv.1@cs.cmu.edu> spot@CS.CMU.EDU (Scott Draves) writes:
|> >i've written a lot of SML and lisp code, and my experience is that
|> >syntax (especially ()s) is not a problem in lisp, but that i do have
|> >problems (understanding and writing) SML.
|> 
|>   Sorry, I just don't believe you. To me, Lisp has the most disgusting syntax
|> imaginable. However I don't like the ML/Haskell convention of using
|> "let x = y in z" rather than "z where x = y", I like to read programs top down
|> rather than bottom up. I have considered having a PC opinion about this
|> syntax, i.e. you like what you're used to, but I honestly believe that Lisp
|> syntax is inherently evil.
|> 
|> John

I don't believe him either, John, but just to pick up on the let/where business:

Consider 
   let x = y in if a then b else c
and
   if a then b else let x = y in c

Now consider

    if a then b else c where x = y

To which of the let forms does this correspond?

It's ambiguous, and an arbitrary decision has to be made as to which parse to
use. This is dangerous, as a wrong assumption can result in a syntactically
correct program with entirely the wrong meaning.

So, the let form if better, because it's safer. Otherwise, it's just personal
preference, which is not a very good way to design a language, expecially where
there's a committee with varying preferences!

BTW, Haskell has a where form as well, but it's part of the equation syntax, not 
the expression syntax, so it doesn't cause any problems.

--brian

-- 
Internet: brian@comp.vuw.ac.nz
Postal: Brian Boutel, Computer Science Dept, Victoria University of Wellington,
        PO Box 600, Wellington, New Zealand
Phone: +64 4 471-5328   Fax: +64 4 495-5232
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.functional
Subject: Re: SML Pretty-printing
Date: 6 Oct 92 22:15:57 GMT
Article-I.D.: alice.23825
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

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:

> 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... *)

No problem -- the program is a syntax error.

In the absence of other delimeters, a `case' eats all the clauses it can,
so in fact this program should have been indented this way:

	fun testcase (x,y) =
	  case x of
	    Alpha _ => ()
	  | Beta _ =>
	      case y of
	        Happy _ => ()
	      | Dopey _ => ()
	      | Grumpy _ => ()
	      | Gamma _ => ();

to correspond to the way it's parsed.  That in turn generates a type error.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.functional