HDTenEightyP/NetNews huggingface dataset:
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Re: Why functional languages?
Organization: PTT Research
Date: Tue, 29 Sep 1992 08:11:39 GMT

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

>Well, in SML, that would be:

>   I(
>     Don( Q( t(
>		think(
>		      so()))))) (bang).

>That doesn't look any prettier to me.

Sorry, I didn't mean to actually merge into the discussion. I'm
more in favour of more friendly languages such as the Haskell-
family. In fact, the only thing I know about Lisp is that is uses
lots of )))))))):)

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
Newsgroups: comp.lang.functional
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Unique types etc.
Keywords: Unique types, linear types, linear logic
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 2 Oct 1992 18:41:12 GMT

kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:

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

Yes, I believe so.
(Who am I to answer this question? I had never heard of either of them
until they came up here! But from my limited understanding, yes :-)

On the other hand if I were implementing arrays with destructive
update, I would not use exactly what has described as linear types or
unique types.  When we are talking about I/O states, it is not possible
to refer to the same state more than once - once you have invoked some
I/O operation, the state has changed and it may be physically
impossible to return to the old state.  Thus you must issue an error
message if a program tries to use the same I/O state twice. However
with arrays, you *can* refer to them twice - it's just not as efficient
that way. Instead of issuing an error message when an array is used
twice, you should automatically copy the array, perhaps issuing a
warning at most.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.functional
From: stodghil@cs.cornell.edu (Paul Stodghill)
Subject: Re: Why functional languages?
Organization: Dept. of Comp. Sci., Cornell U.
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
Date: Thu, 1 Oct 1992 15:27:32 GMT

In article <26463@castle.ed.ac.uk> jamesh@castle.ed.ac.uk (James Hammerton) writes:

   [ Bunch o' stuff discussing "(prefix)" notation vs. "prefix()" and infix
     notation deleted. ]

   The original poster was talking about the ease with which one lisp
   program could manipulate another(or itself), not readability as such.

I don't find the argument that "list-notation is easier to manipulate than
other notations" convincing. It seems to ignore the fact that people have
been manipulating abstract syntax trees for years. It is true, however,
that AST's are not a basic data type in most of these languages, and lists
are.
Newsgroups: comp.lang.functional
From: bjornl@sics.se (Bj|rn Lisper)
Subject: Re: More's array theory
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 5 Oct 1992 17:00:05 GMT

Well, I received one answer to my query on More's array theory last week.
Since I promised to summarize, here it is.

Bjorn Lisper

To: Bj|rn Lisper <bjornl@sics.se>
Reply-To: Jay.Sipelstein@cs.cmu.edu
Subject: Re: More's array theory
Date: Tue, 29 Sep 92 12:41:11 EDT
From: sippy@DEBUBLY.SCANDAL.CS.CMU.EDU


In article <BJORNL.92Sep29114213@asia.sics.se>, you write:
>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?

I posted a query about references to More's work about a year ago
on comp.lang.apl, and didn't get any useful responces.  Here is a 
list of references that I've been able to compile:

Trenchard More: Axioms and Theorems for a theory of arrays
        IBM J Research and Development
        vol 17 num 2 pages 135-175
        1973

T. More: On the Composition of Array Theoretic operations
        Tech Report 320-2113
        IBM Cambridge Scientific Center
        1976

T. More: The Nested Rectangular Array As a model of data
        Proceedings APL79
        pages 55-73
        1979

T. More: Nested Rectangular Arrays for measures addresses and paths
        Proceedings APL79
        pages 156-163
        1979

T. More: notes on the diagrams logic and operations of array theory
        in Structures and Operations in Engineering and Mangement Systems
        Edited: O. Bjorke and O. Franksen
        Published: Tapir Publishers, Trondheim, Norway
        Pages: 497-666
        1981


He also had a paper in the 1990 APL proceedings which was described 
as an extended abstract of a "final" array theory.  I haven't been able
to locate the final version of the paper, and that paper had no
bibliography.  I believe that you can get all the IBM array theory
TRs by asking IBM for them by topic ("send me all the array theory
papers by More").

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

Please send me mail summarizing any responses you receive, especially
about his later work.

>Bjorn Lisper

Jay Sipelstein
sipelstein@cs.cmu.edu
Newsgroups: comp.lang.functional
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Re: Why functional languages?
Organization: PTT Research
Date: Mon, 28 Sep 1992 16:02:31 GMT

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


>I think in order to fulfill their promise in this area, functional
>programming languages should probably go back to Lisp notation.

(I
  (Don (' (t
	     (think
		   (so)))))) (!).
-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
Newsgroups: comp.lang.functional,comp.lang.lisp
From: ramaer@cs.utwente.nl (Mark Ramaer)
Subject: Re: 3rd order functions
Organization: University of Twente, Dept. of Computer Science
Date: Mon, 5 Oct 1992 10:13:23 GMT

In article <ALTI.92Oct2123450@tanera.dcs.ed.ac.uk>, alti@dcs.ed.ac.uk (Thorsten Altenkirch) writes:
|> 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.
|> 

Sorry, I have chosen a wrong example.  This function is from the same file:

cat >Try.lhs <<eoscript
> module Try(join) where

join :: (a -> b -> c) -> Parser t r a -> Parser t r b -> Parser t r c

> join semantic aa bb cont
>	= aa aCont
>	  where aCont a = bb (bCont a)
>		bCont a b = cont (semantic a b)
eoscript

Now hbc derives the type (note that my type specification is a comment):
join :: (a -> b -> c) -> ((a -> d) -> e) -> ((b -> f) -> d) -> (c -> f) -> e

(N.B. in the entire program d === e === f === [t]->r)

That should do,
Mark
Xref: sparky comp.lang.functional:1194 comp.lang.lisp:2577 comp.lang.scheme:2314
From: freeman@gradient.cis.upenn.edu (Jon Freeman)
Newsgroups: comp.lang.functional,comp.lang.lisp,comp.lang.scheme
Subject: The speed of various functional languages
Date: 3 Oct 92 18:48:10 GMT
Followup-To: comp.lang.functional
Organization: University of Pennsylvania

This is not a question that I would normally ask, but unfortunately I
need to ask it and I need answers as soon as possible...

In the personal experience of people on the net, which widely
available implementation of a functional language is the fastest on
comparable programs?  I'm thinking about language-implementation pairs
like MIT Scheme, Lucid Common Lisp, Franz Lisp, etc.

Here's why I'm asking: I have been writing search algorithms for the
CNF-satisfiability problem in Standard ML of New Jersey, version 0.75.
Although I like SML very much, and I think its static type-checking is
fantastic for program development, I'm afraid I have to admit that its
performance on my algorithms, at least, is simply terrible.

First, let me illustrate this claim with a specific example.  There's
a local search algorithm for CNF-satisfiability called GSAT.  The most
recent paper on GSAT is available via anonymous ftp from
research.att.com in the directory /dist/ai.  Like all local search
algorithms, GSAT is very simple: it's essentially two nested FOR
loops.  According to the above paper, the authors' implementation of
GSAT (written in C) can solve the 8, 20, and 30-queens problems in
0.1, 0.9, and 2.5 seconds, respectively.  My SML implementation of
GSAT, on the other hand, requires an average of 3, 70, and 500 seconds
of CPU time, respectively.  GSAT's simplicity makes these results
particularly troubling.  My _backtracking_ search algorithms are also
much slower than their counterparts in the literature.

Second, let me emphasize that the speed of the language I use is not
_directly_ important to what I'm trying to accomplish.  If it were, I
could get a Ph.D. by simply writing my programs in assembly language.
I need a sufficiently fast language only because I have to test my
algorithms on fairly large problems, and run lots and lots of trials,
in order to convice people that the complexity of my search algorithms
is what I say it is.

Third, I would prefer to continue using a functional language because
the thought of rewriting these tedious algorithms in C or C++ sends
chills up my spine.  I would prefer to work in a Lisp-y language; I
used to program extensively in Scheme.

Thank you very much for your help in this matter.  Again, I'm not
trying to criticize SML unnecessarily, but at this point I'm simply
dead in the water until I switch to a faster language.

			Sincerely,
			 Jon
			 (freeman@gradient.cis.upenn.edu)

P.S. Please email all replies; I don't want to be responsible for
starting any flame wars.
Newsgroups: comp.lang.functional
From: farrell@coral.cs.jcu.edu.au (John Farrell)
Subject: let/where syntax war
Organization: James Cook University
Date:  4 Oct 92 23:38:51 GMT

In <BvHIwz.9HM@comp.vuw.ac.nz> brian@comp.vuw.ac.nz (Brian Boutel) writes:
>In article <farrell.718005712@coral>, farrell@coral.cs.jcu.edu.au (John Farrell) writes:
|>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.

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

  To me it seems that "let" is a command to the reader, and by the time I have
informed myself that x = y, I have forgotten why I was reading the code in the
first place. I think "let" sounds more like an imperative command than a
functional expression, e.g. "LET" is BASIC syntax.
  Anyway, while I'm at it, I don't like the "a | b = c" syntax either, but I
suspect that's because I haven't learnt to read "|" as being "if" and "=" as
being "then". I much prefer some sort of arrow notation, but I can't think of
a good one right now.
  As people who don't know me might have guessed, I'm a Miranda weenie and I
love Miranda syntax (BTW, if David Turner is reading this, I am moving to Gofer
because it is free and is available on the PC). Now continuing my love of
ambiguity, I would like to say that I don't care if a language is ambiguous,
just so long as I know what it means :-). I.e. I would much rather write "where"
clauses with brackets to resolve ambiguity than write "let" expressions which
confuse me straight away.
  Which reminds me! Why the difference between "let" and "letrec"? Surely we
have got past the stage of explicity flagging recursive functions? I know that
(well, I believe that) an expression can have different meanings depending on
whether a token is a "let" or a "letrec", but surely it's dangerous to have a
name refer to two different values depending on three little letters?

John
From: bennet@coho.cse.ogi.edu (Bennet Vance)
Newsgroups: comp.lang.functional
Subject: Re: SML Pretty-printing
Date: 6 Oct 92 22:13:52 GMT
Article-I.D.: ogicse.43730
Organization: Oregon Graduate Institute - Computer Science & Engineering

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.

By the same token (so to speak), any parser for SML would also have to
be able to discriminate between the constructors of foo and those of bar
(at parse time!) if it were to parse this program as the author intends.
The given program is rejected by the SML/NJ compiler...

Bennet Vance
Newsgroups: comp.lang.functional
From: farrell@coral.cs.jcu.edu.au (John Farrell)
Subject: Re: Why functional languages?
Organization: James Cook University
Date:  4 Oct 92 23:27:36 GMT

In <1992Oct2.053333.20373@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>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.

  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.

John
From: kees@imada.ou.dk (Kees de Bruin)
Newsgroups: comp.lang.functional
Subject: Documentation required
Summary: documentation on implementation of higher order functions
Keywords: functional languages, high-order functions, closure models
Date: 29 Sep 92 18:17:58 GMT
Organization: Dept. of Math. & Computer Science, Odense University, Denmark

Hello everybody,

I'm a student at Delft University and am currently working on a implementation
for higher order functions in a functional programming language. I know the
most commen used model for this is the closure model, but I can't find any
literature about the closure model, or about implementing higher order
functions itself. I have got the book of Peyton-Jones (implementation of
functional programming languages) but this does not say anything about how
to implement higher order functions.

I know how the closure model works, but I need some background on the subject.
Is there anyone who has got some ideas?

Thanks,

Kees de Bruin.

PS. Please post your answer to the net, or use the email address below (in
    Denmark)

+----------------------------------------------------------------------+
| When someone says, "I want a programming language in which I need    |
| only say what I wish done," give hime a lollipop.                    |
|                                                        (Alan Perlis) |
+----------------------------------------------------------------------+
| Kees de Bruin                                                        |
| Department of Technical Mathematics and Informatics                  |
| Delft University of Technology, The Netherlands                      |
| Email: bruin@dutiab.twi.tudelft.nl                                   |
| Current email: kees@ifad.dk                                          |
+----------------------------------------------------------------------+
Newsgroups: comp.lang.functional
From: ted@nmsu.edu (Ted Dunning)
Subject: Re: Why functional languages?
Reply-To: ted@nmsu.edu
Organization: Computing Research Lab
	<TMB.92Sep28223555@arolla.idiap.ch> <26463@castle.ed.ac.uk>
Date: Tue, 6 Oct 1992 00:14:35 GMT


In article <26463@castle.ed.ac.uk> jamesh@castle.ed.ac.uk (James Hammerton) writes:

   With long programs, the ease with which you can read them becomes very
   important. I can imagine that with a long lisp program, checking that
   all the brackets are in the right place could become a nightmare,(though
   a good programming style would alleviate some of the worst cases), where
   the ML equivalent would allow you to forget this particular gripe.



this is a common misconception of people who haven't used lisp to any
degree. 

when you read lisp, you read indentation.  when you write lisp, you
use the parens to tell the editor how to indent your code.  this is
actually easier to edit and read than most other syntaxes.
Newsgroups: comp.lang.functional
Subject: Linear types (was Re: Unique types etc.)
From: jeremy@cs.aukuni.ac.nz (Jeremy Gibbons)
Date: Mon, 5 Oct 1992 01:10:20 GMT
Organization: Computer Science Dept. University of Auckland
Keywords: Unique types, linear types, linear logic

In <1992Oct2.083300.20958@kth.se> kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:

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

Newsgroups: comp.lang.functional
From: dbm@allegra.att.com (Dave MacQueen)
Subject: concrete vs abstract syntax or syntax trees
Date: Tue, 29 Sep 1992 03:09:40 GMT
	<TMB.92Sep28144424@arolla.idiap.ch> <annius.717696151@freyr>
	<TMB.92Sep28223555@arolla.idiap.ch>
Organization: AT&T Bell Laboratories

It is certainly nice to be able to manipulate programs in terms of a
straightfoward structural representation.  However, this doesn't mean
that one has to be content with a primitive concrete syntax such as
Lisp's.  It suffices to have a parser that translates one's concrete
syntax into a more convenient representation for manipulation by
programs.  For instance, the next release of SML of NJ will provide
a syntax tree datatype, currently called ast (but this name may change
before the release) which is fairly close to the concrete syntax.
Of course, parentheses have nothing to do with the representation of
of programs in terms of a syntactic datatype.  [Note also that Lisp
S-expressions are not equivalent to an abstract syntax representation
for Lisp -- most S-expressions do not correspond to well formed Lisp
programs or expressions.]

Anyone who prefers Lisp style concrete syntax is free to define such
a syntax for, say, Standard ML.  They could then write a parser that
would translate their syntax into a type like ast for processing by
the rest of the compiler.  The ast representation mentioned above is
"pre-elaboration", meaning static analysis and type checking take
place after the construction of the ast representation of a program.
This makes the parser's task fairly simple.

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

I would prefer to use different notations for (2) and (3).  Angle
brackets would be appropriate for (2), but are unfortunately not
available in ascii (maybe it's time to move on to the ISO Latin 8 bit
character set?).  For (3) the traditional Algol "begin ... end"
notation would probably be fine.

Dave MacQueen
macqueen@research.att.com
Room 2A-431, AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ 07974
--
Dave MacQueen
macqueen@research.att.com
Room 2A-431, AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ 07974
From: beshers@tsavo.hks.com (George Beshers)
Newsgroups: comp.lang.functional
Subject: Re: SML Pretty-printing
Date: 6 Oct 1992 19:21:49 GMT
Organization: HKS, Inc.
Distribution: world
Reply-To: beshers@hks.com
NNTP-Posting-Host: tsavo.hks.com


# 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 SML compiler which accepts this is wrong, i.e., as I
read the rules an error message should be generated (sorry
I can't quote the rule numbers as the definition is at home).
However, having made the mistake, I agree that this bit
of SML syntax is a mis-feature.

In general, if a syntax is designed for small examples then
closing brackets can `be safely omitted'.  When the examples
start to get large the `safely' is invalidated.

The time spent (and the in elegance of) esac, fi, nf, etc. is
negligible compared with problems of mis-interpretation.