HDTenEightyP/NetNews huggingface dataset:
From: carlton@scws8.harvard.edu (david carlton)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 5 Oct 92 18:08:56 GMT
Article-I.D.: scws8.CARLTON.92Oct5110856
 <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>
Organization: Citizens for Boysenberry Jam
In-reply-to: tmb@arolla.idiap.ch's message of 4 Oct 92 22:18:21 GMT

In article <TMB.92Oct4181821@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

> Why _do_ people continue to use curried syntax when they just want a
> function with several arguments? It's difficult to optimize for the
> compiler, it gives uninformative type signatures (is "'a -> 'a -> 'a"
> intended to be a function of one argument returning a function, or is
> it intended to be a function of two arguments returning a "'a"?), it's
> not what most programmers are used to, and it seems to be difficult to
> indent automatically as well.

Why does SML support functions of multiple arguments using both tuples
and curried functions, anyways?  Strikes me as more of a pain than
anything else - some library functions call for functions that use
tuples for multiple arguments, some want curried functions, etc., and
things would be simpler if there were one standard way to do it.  Is
this simply a historical carry-over, or is there some better reason?
And how much of a problem is it in practice?  I've only programmed a
little in SML, and while it was a bit of a problem, it wasn't too much
of a problem for what I was doing; but I could imagine that it could
be more of one in some situations.

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"?

david carlton
carlton@husc.harvard.edu

       If a person is FAMOUS in this country, they have to go on the
       ROAD for MONTHS at a time and have their name misspelled on the
       SIDE of a GREYHOUND SCENICRUISER!!
Xref: sparky comp.lang.functional:1196 comp.theory:2123
From: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Subject: Re: Unique types etc.
Keywords: Unique types, linear types, linear logic
Reply-To: kff@dentex.tds.kth.se (Karl-Filip Faxen)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Fri, 2 Oct 1992 08:33:00 GMT

Hello!

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. The major application so far
seems to have been the array update problem (guaranteeing that
arrays are used in such a way that array update can safely be 
implemented without copying).

So, are unique types the same as linear types?

Curious cheers,

                   Karl-Filip

------------------------------------------------------------
Make the frequent case fast, and the fast case frequent!
Newsgroups: comp.lang.functional
From: spot@CS.CMU.EDU (Scott Draves)
Subject: Re: Why functional languages?
Originator: spot@HOPELESS.MESS.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon University
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
Date: Fri, 2 Oct 1992 01:06:29 GMT

>>>>> On 1 Oct 92 12:57:12 GMT, jamesh@castle.ed.ac.uk (James Hammerton) said:


jamesh> (define fac
jamesh>  (lambda (n)
jamesh>   ( if (= 0 n)
jamesh>     1
jamesh>     (* n (fac (- n 1))))))



jamesh> fun fac 0 = 1
jamesh> |   fac n = n * fac (n-1) ;


jamesh> Now which is easier to read?!!!

this is the standard argument one sees.  i agree that for this trivial
example the SML syntax is more quickly understood.  that's why some
language designers make this mistake.  it's a fine for a toy language.
and given SML's theoretical lineage, it's not surprising that things
ended up as they have (local optimization -> local maximum != global
maximimum).

but the answer to your question isn't important.  real programs aren't
that short.  large lisp functions retain their clarity.  large SML
functions are horrid messes.  this is taken from the compiler itself
(something i work on).  i didn't even have to try and find something
bad...  (* Copyright 1989 by AT&T Bell Laboratories *).

    and getroot(APP(VAR f,wl)) = (f,mix(wl,standardformals wl))
      | getroot(APP(LABEL f,wl)) = 
         (case know f 
            of KNOWN((vl,e),ref(SOME fmls)) => (f,mix(wl@(map VAR vl),fmls@fmls))
	     | KNOWN((vl,e),ref NONE) => 
                   (let val tmp = targeting(wl,vl,e)
                     in (f,tmp)
                    end)
	     | KNOWN_CHECK((vl,e),ref(SOME fmls),_) => (f,mix(wl@(map VAR vl),fmls@fmls))
	     | KNOWN_CHECK((vl,e),ref NONE,_) => 
                   (let val tmp = targeting(wl,vl,e)
                     in (f,tmp)
                    end)
	     | STANDARD _ => (f,mix(wl,standardformals wl))
	     | _ => die "a10 in CPSgen")




jamesh>  Even with such a simple example, it's not obvious that the
jamesh> close brackets at the end of the lisp version are enough,

i suppose you don't use an editor that matches ()s for you.


jamesh> where it's immediately obivous that the ML version has the
jamesh> correct syntax.

where's the obvious syntax error in this:

datatype foo = FOO of x
fun bar FOO x = x


jamesh> With long programs, the ease with which you can read them
jamesh> becomes very important. I can imagine that with a long lisp
jamesh> program, checking that all the brackets are in the right place
jamesh> could become a nightmare,

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.


jamesh> ... As such many programs can be proven equivalent or correct
jamesh> mathematically in SML, since the notation is highly
jamesh> mathematical.

sigh.

if someone else would like to defend SML syntax, please do so...
-- 
			forms
Scott Draves		contracts
spot@cs.cmu.edu		standards
Newsgroups: comp.lang.functional
From: farrell@coral.cs.jcu.edu.au (John Farrell)
Subject: Re: Why functional languages?
Organization: James Cook University
Date: 30 Sep 92 04:54:52 GMT

In <1992Sep26.212935.26809@eng.umd.edu> clin@eng.umd.edu (Charles Lin) writes:
>   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.

  I think functional language compiler writers will be addressing a question
which is very important for compiler writers for all languages:

  Why does that other compiler produce better code than mine, and how can I
  change mine to do the same thing?

For functional language compiler dudes, they are a heck of a long way away
from a C compiler, but on the other hand they have referential transparency
to help them along.

John
From: brent@ssd.csd.harris.com (Brent Benson)
Subject: Re: Why functional languages?
Organization: Harris Computer Systems
Date: Fri, 2 Oct 1992 14:10:19 GMT
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
	<BvGz2u.2rv.1@cs.cmu.edu> <farrell.718005712@coral>

farrell@coral.cs.jcu.edu.au (John Farrell) writes:

> Sorry, I just don't believe you. To me, Lisp has the most disgusting
> syntax imaginable... I honestly believe that Lisp syntax is
> inherently evil.

That's what I like, a nice substantiated argument with an honest look
at both sides of the question.  

Seriously, I don't see what we have to gain by this posturing.  There
are obviously arguments for and against both points; why keep
insisting that the other guy is wrong?  Use your favorite syntax.
Write a parser that transforms your favorite syntax into whatever
language you happen to be using.  Make it available and see if people
use it.

--
Brent Benson                     
Harris Computer Systems
Newsgroups: comp.lang.functional
From: lindig@ips.cs.tu-bs.de (Christian Lindig)
Subject: Where to get DYLAN informations ?
Reply-To: lindig@ips.cs.tu-bs.de
Organization: Inst. f. Informatik, TU Braunschweig, FRG
Date: Sun, 27 Sep 1992 16:33:17 GMT


A few weeks ago Apples new language Dylan was discussed. Someone
mentioned an email-adress  where one can retrieve more informations
about Dylan. I'm looking for that adress and the title (and ISBN) of
the book, where Dylan is described. All other hints to informations
regarding Dylan are also welcome. Please reply by mail - if there is
enough interest I will post a summary.

Thanks,

Christian

------------------------------------------------------------------------
 Christian Lindig  				 lindig@ips.cs.tu-bs.de
------------------------------------------------------------------------
From: sjt@ukc.ac.uk (S.J.Thompson)
Newsgroups: comp.lang.functional
Subject: Re: 3rd order functions
Date: 1 Oct 92 12:48:00 GMT
Reply-To: sjt@ukc.ac.uk (S.J.Thompson)
Organization: Computing Lab, University of Kent at Canterbury, UK.


A ``real'' third-order function:

A real number can be represented by a first order function

	integer -> integer

or 

	integer -> rational

Functions from reals to reals are therefore second order, and
so a function which integrates a real function over an interval 
is third order:

	(real -> real) -> real -> real -> real

Simon Thompson

Simon Thompson				e-mail:	sjt@ukc.ac.uk
Computing Laboratory			phone:	+44-227-764000 extn. 3820
University of Kent			fax:	+44-227-762811
Canterbury, Kent,
CT2 7NF, UK
Newsgroups: comp.lang.functional
From: bjornl@sics.se (Bj|rn Lisper)
Subject: More's array theory
Organization: Swedish Institute of Computer Science, Kista
Date: Tue, 29 Sep 1992 10:42:13 GMT

Some time ago I saw postings in this newsgroup on More's array theory.
Unfortunately I didn't keep them. I would like to know a little more about
this subject. Could somebody provide me with references?

Answers preferrably via e-mail. If there is interest I will summarize and
post.

Bjorn Lisper

bjornl@tds.kth.se
From: carlton@scws4.harvard.edu (david carlton)
Newsgroups: comp.lang.functional
Subject: Re: Why curry? (Re: Why functional languages?)
Date: 6 Oct 92 00:17:08 GMT
 <annius.717696151@freyr><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: Citizens for Boysenberry Jam
In-reply-to: nickh@CS.CMU.EDU's message of Mon, 5 Oct 1992 21:09:04 GMT

In article <NICKH.92Oct5160904@VOILA.VENARI.CS.CMU.EDU>, nickh@CS.CMU.EDU (Nick Haines) writes:
> 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.

Sure, I understand that; and if I wanted to define functions taking
multiple arguments which were implemented by lists or some other
method, I could.  It's just that the language itself supports tuples
and curried functions more than it does other ways of implementing
multiple arguments.  For example, there is special syntax for writing
curried functions; if you convert an infix function to a prefix
function, you get a function taking a 2-tuple as an argument; various
library functions use the one form or the other for multiple arguments
or accept functional arguments using the one form or the other;
various library functions taking multiple arguments even come with
both a curried version of the function and a tuple version of the
function.  (I'm not familiar enough with the language to know whether
or not those last two are part of the language definition, but their
existence in some implementations shows that this is an issue.)  So
it's more complicated than just saying "All functions in SML take one
argument."

david carlton
carlton@husc.harvard.edu

       Did I do an INCORRECT THING??
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: Why functional languages?
Date: 28 Sep 92 18:44:24 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: torbenm@diku.dk's message of 28 Sep 92 12:02:25 GMT


   My primary interest in functional languages is not ease of programming
   from a human viewpoint (after all, adding imperative features to a
   pure FL will not make programming in it harder), but the ease of
   manipulating programs.

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 think in order to fulfill their promise in this area, functional
programming languages should probably go back to Lisp notation.
Furthermore, some standardization work on interfaces still needs to be
done. Hopefully, the result would be cleaner than what Lisp has to
offer right now.

					Thomas.

PS: What statically typed functional languages with Lisp-like notation
are available? I believe MIT has something; can that be FTP'ed?
Newsgroups: comp.lang.functional
From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Subject: Re: Workshops in J
Organization: Iverson Software Inc.
Date: Sun, 27 Sep 92 14:52:34 GMT

Leander Conradie writes:
 
> This may be an FAQ, but can anyone please give me some reference on J?
 
J is an APL-like functional array language.  The source and executables
for various machines are available by FTP from watserv1.uwaterloo.ca.
Therein can also be found a short write-up on it by Prof. L.J. Dickey
(ljdickey@watmath.uwaterloo.ca).

------------------------------------
Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
Phone: (416) 925 6096;  Fax: (416) 488 7559
From: sansom@dcs.gla.ac.uk (Patrick Sansom)
Newsgroups: comp.lang.functional
Subject: Generational GC and Lazy Functioanl Languages
Date: 28 Sep 92 16:03:49 GMT
Organization: Glasgow University Computing Science Dept.
Return-Path: <sansom@dcs.gla.ac.uk>
X-Mailer: mail-news 2.0.5


Does anyone out there have any references for practical work
describing experience using generational garbage collection
schemes with lazy functional languages.

Ta, Patrick.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Why curry? (Re: Why functional languages?)
Date: 4 Oct 92 22:18:21 GMT
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
	<BvGz2u.2rv.1@cs.cmu.edu> <NICKH.92Oct2134230@VOILA.VENARI.CS.CMU.EDU>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: nickh@CS.CMU.EDU's message of 2 Oct 92 18:42:30 GMT


      datatype foo = FOO of x
      fun bar FOO x = x

	     (     )
   Missing parens, of course; you didn't really want a curried function
   of type (x -> foo) -> 'a -> 'a, did you? What's the problem? Anyone
   who's done much work in SML should recognise immediately that

	   fun bar x y = 

   defines a curried function.

Why _do_ people continue to use curried syntax when they just want a
function with several arguments? It's difficult to optimize for the
compiler, it gives uninformative type signatures (is "'a -> 'a -> 'a"
intended to be a function of one argument returning a function, or is
it intended to be a function of two arguments returning a "'a"?), it's
not what most programmers are used to, and it seems to be difficult to
indent automatically as well.

When I started using SML, I found curried syntax "cute" for, but after
a few months, I began to find it rather bothersome, and now, I have
completely switched over to tupled syntax (including my own "standard"
library).

					Thomas.
Newsgroups: comp.lang.functional
From: fpk@munta.cs.mu.OZ.AU (Francisco KU)
Subject: Re: logic-functional
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 1 Oct 1992 00:09:08 GMT

opalla@owl.informatik.uni-dortmund.de (Rudolf Opalla) writes:

>I don't know if this is the correct group, but if anyone is interested - I
>have posted the logic-functional language-system ALF to ftp.germany.eu.net
>(simpson.germany.eu.net).
[Deleted...]

	You forgot to set the read permission for the world!!!

----------------
fpk@cs.mu.oz.au
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.functional
Subject: Re: Why functional languages?
Date: 5 Oct 92 02:52:24 GMT
Article-I.D.: alice.23802
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

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. The
> ability to make syntax errors is a virtue.

Well, no; it's easy to make syntax errors in Lisp.  It's just that if you're
running in interpreted mode, they aren't caught until you try to execute.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: miller@diego.llnl.gov (Patrick Miller)
Newsgroups: comp.lang.functional
Subject: Re: Why functional languages?
Date: 29 Sep 92 17:06:30 GMT
Organization: Lawrence Livermore National Laboratory

In article <1992Sep28.183322.29254@m.cs.uiuc.edu>, hasker@m.cs.uiuc.edu (Rob Hasker) writes:
|> All you need is a parser which translates the concrete syntax to the abstract
|> syntax (i.e., Lisp-like notation), and an "unparser" to translate back.  This
|> way the user gets the benefit of being able to write readable code and the
|> rewrite engine doesn't have to parse anything.  This approach works very well
|> for the transformation system on which I'm working (Uday Reddy's Focus system).
|> 
|> Rob

We do something similar in SISAL (Streams and Iteration in a Single
Assignment Langauge for the curious).  We maintain a functional
intermediate language (IF1) below the programmer source level.  We can
actually do code optimizations and other code re-writes and then
``uncompile'' the result back to SISAL!

Again, we get the advantages of human readible, functional code
without losing the advantages of a fully functional backend.

-- 
Pat Miller                            I have many opinions, but they
patmiller@llnl.gov                      generally aren't humble ones
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: concrete vs abstract syntax or syntax trees
Date: 2 Oct 92 23:36:06 GMT
	<TMB.92Sep29100759@arolla.idiap.ch>
	<1992Sep30.175841.19500@cs.cornell.edu>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: tyan@cs.cornell.edu's message of 30 Sep 92 17:58:41 GMT

In article <1992Sep30.175841.19500@cs.cornell.edu> tyan@cs.cornell.edu (Thomas Yan) writes:

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

McQueen was suggesting using different syntax for constructing tuples.
I very much object to that, since the current syntax makes tupled
function calls (the most common case of function call, unless you
happen to curry everything) look "normal":

	f(x,y,z)

looks much nicer to me than something like

	f[< x, y, z >]

					Thomas.
From: opalla@owl.informatik.uni-dortmund.de (Rudolf Opalla)
Newsgroups: comp.lang.functional
Subject: logic-functional
Date: 30 Sep 1992 13:44:59 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: owl

I don't know if this is the correct group, but if anyone is interested - I
have posted the logic-functional language-system ALF to ftp.germany.eu.net
(simpson.germany.eu.net).

ALF (Algebraic Logic Functional programming language)
is a language which combines functional and logic programming techniques.
The foundation of ALF is Horn clause logic with equality
which consists of predicates and Horn clauses for logic
programming, and functions and equations for functional programming.
Since ALF is an integration of both programming paradigms,
any functional expression can be used in a goal literal and
arbitrary predicates can occur in conditions of equations.
The abstract machine is based on the Warren Abstract Machine (WAM)
with several extensions to implement narrowing and rewriting.
In the current implementation programs of this abstract machine are
executed by an emulator written in C.

You can find it in the path "/pub/programming/languages/LogicFunctional".
There are three files which contain:
  - alf_sys.zoo:  - Documentation (englisch),
                  - C-Sources (for the emulator) - should work with all 16/32
                    bit-systems,
                  - Compiled version of the preprocessor (see below)
                  - Compiled version of the compiler         "
                  - some basic modules
                  - small examples

  - alf_pp.zoo:   ALF-Sources for the preprocessor (type-checking, manages a
                  modul-concept, ...)

  - alf_comp.zoo: ALF-Sources for the compiler, translates the preprocessors
                  output to:
                  - a file which is executable through the emulator
                  - WAM-like instructions (text)

 ____________________________________________________________
|                                                            |
| Rudolf Opalla  -  opalla@julien.informatik.uni-dortmund.de |
|____________________________________________________________|
Newsgroups: comp.lang.functional
From: quale@saavik.cs.wisc.edu (Douglas E. Quale)
Subject: Re: Why functional languages?
Organization: Undergraduate Projects Lab, UW Madison
Date: Fri, 2 Oct 1992 05:33:33 GMT

In article <26463@castle.ed.ac.uk> jamesh@castle.ed.ac.uk (James Hammerton) writes:
>
>Now which is easier to read?!!!(Given that you are well versed in both
>notations) Even with such a simple example, it's not obvious that the
>close brackets at the end of the lisp version are enough, where it's
>immediately obivous that the ML version has the correct syntax.
> 

My experience with SML and lisp is exactly the reverse.  I (almost!) never
make syntax errors in lisp, and on the exceedingly rare occasions that I do
I can spot them instantly.

I like SML's pattern matching and type checking, but the syntax is gruesome
-- it's by far the worst part of the language.  Syntax errors in even toy
SML programs have had me pulling out my hair.  SML syntax is messy and
irregular.  Some SML constructs are explicitly delimited, some implicitly.
Yuch.

On another note, to compare the ease of computer manipulation of SML and
lisp programs, consider an SML pretty printer vs a lisp pretty printer.
Also consider the ease of implementing and using macros in the two languages.

(Completely off the subject), SML does have CL packages whipped.
-- 
Doug Quale
quale@saavik.cs.wisc.edu
Newsgroups: comp.lang.functional