I recently made the somewhat foolish mistake of selecting the topic for
a term paper in a Language Concepts class thusly: "Programming Languages
with Connections to the Lambda Calculus". The subtitle is, in proper
Scheme style, "or \\ LAMBDA: the Ultimate Programming Language".
The local libraries are rather lacking in this, as the only books I can
find are:
_The_Lambda_Calculus_ by Barendregt (which I've already read the edges
off of), some topology books with interesting surface topologies, a
crufty hardbound Interlisp manual, _Let's_Learn_Lisp_ by someone or
other (Siklosky? IFRNAIBUTL), a VAXIMA manual, CLtL1 rebound with scotch
tape, and _Simply_Scheme_. These do me no good as I already speak
Scheme and Lisp and can parse and occasionally generate lambda calculus
(taught myself, so I'm not exactly good at it).
Then I did a search on publications outside MIT. That turned up
woefully few that weren't too heavy and abstract for use.
Help! I need names of languages related in some way to the lambda
calculus. Direct and indirect are both admissible. Here are some I
already know:
Lisp (sorta)
Scheme (duh)
T (duh*2)
ML (I think)
and possibly:
PLANNER (and $\mu$-PLANNER)
CONNIVER (? never seen it, so I'm guessing)
and those last two I can't find any decent papers on (found the
$\mu$-PLANNER FM, but that doesn't give me any theory). There are some
languages with indirect connections, but I'm not a language lawyer so I
hesitate to make any guesses without sufficient reference material to
back them up.
After the list, some pointers to relevant data would be helpful. I need
mostly language design and (some) implementation theory, hopefully from
the minds of the authors. If I could put "personal communication" in
any of my references I know I'd get brownie points for weird references,
especially if it was with one of the language designers.
The local U library is (thankfully) willing to do InterLibraryLoans with
other libs in the nation. Otherwise I'd be sunk.
(flamage 'rant)
My eventual goal is to have a paper that makes all the other papers ever
written for this class look somewhat pathetic in comparison. That's not
a difficult goal because this university tends to churn out people who
should have graduated with a degree in MIS (called "Computer Information
& Office Systems" locally) and not CS. Many of the ones that don't
graduate go on to exciting careers in the petroleum industry writing
20MB VB (the neu-COBOL) 'programs' to sort payroll data. Whee. I intend
to go into research, and am consequently looked upon as insane. "Why do
research when you can make 40 to 80k/yr writing VeeBee programs for big
Oil?" Aargh.
The most awful thing is that the CS program isn't even accredited. We
lost two professors last year, thus narrowing down the department to one
professor, one asst prof, and one adjunct with an office. And someone
in the Math dept became chair of the Math Sciences which includes math,
CS, and sadistics. And the university says they have to keep both
professorial positions closed for a year each to see "if they are
necessary for the continued operation of the department".
I've decided to completely ignore all of the "General Education
Requirements" in favor of taking all the offered CS and Math courses
until I can't stand the school any further, then trying to go somewhere
else on my raw knowledge and charm alone. Grad school or undergrad
doesn't matter, just as long as some decent school will take pity on
this hacker and offer me some work.
I set my sights high tho. When the time is ripe I'll pack up and drive
to Boston headed for you-know-where. Maybe if I get a job hacking UNIX
with some Beantown area fly-by-night ISP I can spend my free waking
hours in the AI lab doing things I shouldn't. Possibly someone will
eventually take notice and take me under their wing. Otherwise I'll
just have fun. If nothing happens there then I'll go to JHU, then CMU,
then Indiana, then wherever, and I might end up at Stanford or
somewhere. Doesn't matter. Just as long as I can come back in ten or
twenty years with a couple MSs and a PhD, then retire as a consultant
and hide in the woods here in Alaska. A log cabin, dish, and windmill
farm are all I'll need. And maybe a llama or two.
(flamage nil)
The non flame part of the message is important. The flamage is (as
usual) frivolous.
advTHANKSance,
cheers,
james
James,
There are _many_different_ lambda calculi. Just about any language
can be related to one of these calculi. Even object-oriented
languages, through the various encoding mechanisms (an area of
extensive current research), can be translated into certain lambda
calculi. Indeed, there are 700 languages that can be mapped into
lambda calculi.
Go track down the papers by Peter Landin from the early- and mid-60's,
as well as Plotkin's classic on call-by name vs call-by-value. If you
can work your way through those papers, that should educate you more
than any class ever will.
'shriram
From: Klaus Schilling
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <8767dgflji.fsf@ivm.de>
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
> I recently made the somewhat foolish mistake of selecting the topic for
> a term paper in a Language Concepts class thusly: "Programming Languages
> with Connections to the Lambda Calculus". The subtitle is, in proper
> Scheme style, "or \\ LAMBDA: the Ultimate Programming Language".
>
> The local libraries are rather lacking in this, as the only books I can
> find are:
> _The_Lambda_Calculus_ by Barendregt (which I've already read the edges
> off of), some topology books with interesting surface topologies, a
> crufty hardbound Interlisp manual, _Let's_Learn_Lisp_ by someone or
> other (Siklosky? IFRNAIBUTL), a VAXIMA manual, CLtL1 rebound with scotch
> tape, and _Simply_Scheme_. These do me no good as I already speak
> Scheme and Lisp and can parse and occasionally generate lambda calculus
> (taught myself, so I'm not exactly good at it).
>
> Then I did a search on publications outside MIT. That turned up
> woefully few that weren't too heavy and abstract for use.
>
> Help! I need names of languages related in some way to the lambda
> calculus. Direct and indirect are both admissible. Here are some I
> already know:
>
> Lisp (sorta)
> Scheme (duh)
> T (duh*2)
> ML (I think)
>
> and possibly:
>
> PLANNER (and $\mu$-PLANNER)
> CONNIVER (? never seen it, so I'm guessing)
Haskell
Gofer
Hope
Miranda
Caml
Mercury
Klaus schilling
From: Brian M. Moore; esq.
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <70g9fq$rtd$1@news.cc.ukans.edu>
James,
Backus' FP is a great langugae for you to look at.
Find the BibTeX reference below. Read Bacuks' paper and then
chase its references. Good luck. I really enjoyed reading your
plan. It gave me some hope. It seems to me that most of the
people I know graduate with more of a MIS than CS degree. I am
glad there's another person who wants to fix that.
--
--Brian
+---------------------------------------------------------+
| Brian M. Moore procedural epistemologist |
| ······@iname.com http://www.ukans.edu/home/mooreb |
+---------------------------------------------------------+
From Bibliography of the Communications of the ACM (cacm1970):
@Article{Backus:1978:CPB,
author = "John Backus",
title = "Can Programming Be Liberated From the {von Neumann}
Style? {A} Functional Style and its Algebra of
Programs",
journal = "Communications of the ACM",
volume = "21",
number = "8",
pages = "613--641",
month = aug,
year = "1978",
coden = "CACMA2",
ISSN = "0001-0782",
bibdate = "Tue Mar 25 13:26:09 MST 1997",
note = "Reproduced in ``Selected Reprints on Dataflow and
Reduction Architectures'' ed. S. S. Thakkar, IEEE,
1987, pp. 215-243.",
abstract = "Conventional programming languages are growing ever
more enormous, but not stronger. Inherent defects at
the most basic level cause them to be both fat and
weak: their primitive word-at-a-time style of
programming inherited from their common ancestor, the
von Neumann computer; their division of programming
into a world of expressions and a world of statements;
their inability to effectively use powerful combining
forms for building new programs from existing ones; and
their lack of useful mathematical properties for
reasoning about programs. An alternative functional
style of programming is founded on the use of combining
forms for creating programs. Functional programs deal
with structured data, are often nonrepetitive and
nonrecursive, are hierarchically constructed, do not
name their arguments, and do not require the complex
machinery of procedure declarations to become generally
applicable. Combining forms can use high level programs
to build still higher level ones in a style not
possible in conventional languages.",
acknowledgement = ack-nhfb,
annote = "Conventional programming languages are growing ever
more enormous, but not stronger. Inherent defects at
the most basic level cause them to be both fat and
weak: their primitive word-at-a-time style of
programming inherited from their common ancestor - the
von Neumann computer, their close coupling of semantics
to state transitions, their division of programming
into a world of expressions and a world of statements,
their inability to effectively \ldots{}",
classcodes = "C6140 (Programming languages)",
classification = "723",
corpsource = "IMB Res. Lab., San Jose, CA, USA",
descriptors = "Programming language; reliability; future outlook; von
Neumann computer; applicative computing system;",
journalabr = "Commun ACM",
keywords = "4.29; 5.20; 5.24; 5.26; algebra of programs;
applicative computing systems; combining forms;
computer metatheory; conventional languages; CR
categories: 4.20; functional style; grecommended91; Key
words and phrases: functional programming;
metacomposition; models of computing systems; program
correctness; program termination; program
transformation; programming languages; Rhighnam;
structured data; theory ak; Turing award lecture; von
Neuman style; von Neumann computers; von Neumann
languages",
treatment = "T Theoretical or Mathematical",
}
_________________________________________________________________
Copyright � 1994-1998, Alf-Christian Achilles <········@ira.uka.de>,
All Rights Reserved.
Comments/suggestions are welcomed: Please fill out the comment form or
send mail to ········@ira.uka.de.
From: John Atwood
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <70ggfd$nsf$1@news.NERO.NET>
>"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
>> I recently made the somewhat foolish mistake of selecting the topic for
>> a term paper in a Language Concepts class thusly: "Programming Languages
>> with Connections to the Lambda Calculus". The subtitle is, in proper
>> Scheme style, "or \\ LAMBDA: the Ultimate Programming Language".
Does that reference imply you're familiar with these papers?
AI memo 353, March 1976, 41 pages,
Lambda: The Ultimate Imperative, Guy Lewis Steele, Jr. and Gerald Jay
Sussman
AI memo 379, November 1976, 47 pages,
LAMBDA: The Ultimate Declarative, Guy Lewis Steele, Jr.
AI memo 443, October 1977, 23 pages,
Debunking the ``Expensive Procedure Call'' Myth or, Procedure Call
Implementations Considered Harmful or, LAMDBA: The Ultimate GOTO, Guy
Lewis Steele, Jr.
AI memo 514, March 1979, 75 pages,
Design of LISP-based Processors, or SCHEME: A Dielectric LISP, or Finite
Memories Considered Harmful, or LAMBDA: The Ultimate Opcode, Guy Lewis
Steele, Jr. and Gerald Jay Sussman
They're online at:
http://www.ai.mit.edu/publications/pubsDB/pubsDB/onlinehtml
Also is:
AI memo 453, May 1978, 75 pages,
The Art of the Interpreter or, The Modularity Complex (Parts Zero,
One, and Two), Guy Lewis Steele, Jr. and Gerald Jay Sussman
>> The local libraries are rather lacking in this, as the only books I can
>> find are:
>> _The_Lambda_Calculus_ by Barendregt (which I've already read the edges
>> off of), some topology books with interesting surface topologies, a
see these Barendregt papers (they're online at
http://www.cs.kun.nl/~henk/papers.html):
The impact of the lambda calculus
Bulletin of Symbolic Logic, volume 3, no 2, 1997.
Tutorial Lambda Calculi with Types (slides)
The quest for correctness
Computable processes
Lambda Calculi with Types
John Atwood
John Atwood wrote:
>
> Does that reference imply you're familiar with these papers?
>
[snip]
Yep, I've printed out all of GLS and Sussman's LAMBDA papers.
Annoyingly enough ghostscript crashed the linux box in our lab when
trying to parse "The Art of the Interpreter", but I found a printer on
campus that could print postscript directly and didn't have any security
or quotas. (We have hardly any paper for the CS dept, tho no quotas are
enforced. I hate this university.) Oddly enough it was in the Computer
Services main office. Hehehe...
So I printed out the rest of them, though I had to do them one per day.
And reload paper as necessary. Very convenient, as long as nobody
notices.
> see these Barendregt papers (they're online at
> http://www.cs.kun.nl/~henk/papers.html):
Heh. Didn't know he had a web page.
BTW, does anyone know what happened to GLS? Now that TM is dead (or so
I've heard) he must be off wandering in the desert.
And why do so few people that were in the CL and Scheme standards avoid
usenet? I've only seen a couple. You'd think that they'd be glad to
hear user and implementor input on the respective designs, but...
cheers,
james
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
> BTW, does anyone know what happened to GLS? Now that TM is dead (or so
> I've heard) he must be off wandering in the desert.
Sun Microsystems, I believe. It's like the desert, only there's
a water cooler and some comfy chairs and computers and...
> And why do so few people that were in the CL and Scheme standards avoid
> usenet? I've only seen a couple. You'd think that they'd be glad to
> hear user and implementor input on the respective designs, but...
Are you kidding? What a waste of time this is!
--
--Keith
This mail message sent by GNU emacs and Linux.
Food, Shelter, Source code.
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
> BTW, does anyone know what happened to GLS? Now that TM is dead (or so
> I've heard) he must be off wandering in the desert.
Guy is one of the driving forces behind Java nowadays -- he is one of the
authors of the Java standard, and spent the last year or so carefully
defining defining the language -- i.e., playing the kind of language-lawyer
role he played in defining the CL spec.
He works at Sun's East Coast lab. As far as I can tell, he's mostly working on
Java-related technology -- a job for which a Scheme/Lisp background is rather
helpful.
I wouldn't describe him as wandering in the desert.
-Olin
Olin Shivers wrote:
> Guy is one of the driving forces behind Java nowadays -- he is one of the
> authors of the Java standard, and spent the last year or so carefully
> defining defining the language -- i.e., playing the kind of language-lawyer
> role he played in defining the CL spec.
>
> He works at Sun's East Coast lab. As far as I can tell, he's mostly working on
> Java-related technology -- a job for which a Scheme/Lisp background is rather
> helpful.
The differences between Java and Lisp/Scheme are far more noticeable than
anysimilarities, but there are at least a few Lispy things in Java: catch and
throw, a
tokenizer (similar to the ratom primitive that read is built out of, though it
annoyingly scans "." as 0.0), garbage collection, and bignums. Was it Guy
that got these included in Java, and was this the result of an attempt to make
the language as Lisp-like as was politically acceptable (i.e. not very much)?
> -Olin
--
Le Hibou (mo bheachd fh�in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS."
-- Erik Naggum
In article <·················@bt-sys.spamblock.bt.co.uk>,
Donald Fisk <···········@bt-sys.spamblock.bt.co.uk> wrote:
...
>.... Was it Guy
>that got these included in Java, and was this the result of an attempt to make
>the language as Lisp-like as was politically acceptable (i.e. not very much)?
I was under the impression that Gosling was no stranger to Lisp.
I imagine you'd have to know something about Lisp to construct a
version of Emacs. :-)
--
Lyman S. Taylor "Any sufficiently advanced technology is
(·····@cc.gatech.edu) indistinguishable from a rigged demo. "
-- paraphrased Arthur C. Clarke
seen somewhere on the USENET
Lyman S. Taylor wrote:
> In article <·················@bt-sys.spamblock.bt.co.uk>,
> Donald Fisk <···········@bt-sys.spamblock.bt.co.uk> wrote:
> ...
> >.... Was it Guy
> >that got these included in Java, and was this the result of an attempt to make
> >the language as Lisp-like as was politically acceptable (i.e. not very much)?
>
> I was under the impression that Gosling was no stranger to Lisp.
> I imagine you'd have to know something about Lisp to construct a
> version of Emacs. :-)
I suppose so.
So what was the reason why they didn't allow methods to be passed
as parameters? Even C allows that for functions. I am aware it is possible
to fake it by using classes with an apply method instead (as is done in Per
Bothner's Kawa), but that isn't anywhere near as convenient.
> Lyman S. Taylor
--
Le Hibou (mo bheachd fh�in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS."
-- Erik Naggum
In article <·················@bt-sys.spamblock.bt.co.uk>,
Donald Fisk <···········@bt-sys.spamblock.bt.co.uk> writes:
DF> So what was the reason why they didn't allow methods to be passed
DF> as parameters [in Java]?
Perhaps because method extraction leads to unsoundness in the type
system? This is an example of a well-known problem with statically
typed OO languages which cannot even be stated in a dynamically typed
one.[1]
Define the object types (`classes'):
Point1 = <x:int, foo: method(Self)->int>
Point2 = <x:int, y:int, foo: method(Self)->int>
with
Point1.foo(self)=self.x
Point2.foo(self)=self.x+self.y
Point2 is a subtype of Point1. Let
p1 = <x=5> : Point1
p2 = <x=5, y=6> : Point2
Assume now that you have an `extract' operation which allows you to
extract a method from an arbitrary object. How are you going to type
this operation?
You might be tempted to allow:
f(p: Point1)=extract(p,foo)(p1)
f: Point1->int
As p2:Point2, subtyping gives p2:Point1. The type system will allow
you to write f(p2), which will lead to a runtime error (as p1 has no
member `y').
(Note that I've written the example with an explicit `extract'
operation, but I am convinced that it happens as soon as you introduce
`usable' first class methods.)
Of course, this does not show that it is impossible to have first
class methods in a statically typed language. It only shows that
methods are not functions, and that making methods first class leads
to tricky typing issues which may or may not be possible to solve. I
think it is quite justified not to include this feature in a
`production' language.
(I've found this example, or a similar one, in Abadi and Cardelli's
book `A Theory of Objects', but I do not know to whom it should be
properly attributed.)
DF> I am aware it is possible to fake it by using classes with an
DF> apply method instead (as is done in Per Bothner's Kawa), but that
DF> isn't anywhere near as convenient.
Yes, but it's sound, and raises no theoretical difficulties.
Sincerely,
J.
[1] I'm sure there's a conclusion to draw from that, but I don't know
what it is.
(Where shall I send the followups? At random, c.l.lisp.)
From: Zane Lewkowicz
Subject: [c.l.lisp,c.l.eiffel,c.object] going on about covariance again (was: Re: GLS)
Date:
Message-ID: <723qrh$84m$1@xs1.xs4all.nl>
[comp.object and comp.lang.eiffel added to Newsgroups: line.]
Juliusz Chroboczek <···@dcs.ed.ac.uk> wrote:
>
<SNIP on a Lispers perspective of covariance, i think.>
>[1] I'm sure there's a conclusion to draw from that, but I don't know
>what it is.
>
>(Where shall I send the followups? At random, c.l.lisp.)
I _think_ that this is the problem that the OO people refer to
as "covariance". I personally believe it to be _the_
outstanding problem in O-O today. I recently posted an article
to comp.lang.eiffel and comp.object entitled "Four Reasons To
Violate The LSP" which generated a rather long thread,
including some excellent references to other people's thoughts
on "the covariance problem". (I especially recommend David
Shang's paper "Is A Cow An Animal?", and the Sather folk's
archive of their discussion of the subject. (Sorry no URLs but
nowadays it is easy to find stuff, isn't it? Let me know if
not and i'll do the necessary spider-wrangling.))
Beware- all of the O-O gurus who responded to my article were,
based on my cursory inspection of the discussion tree, wrong
about at least one of the following very important points:
1. The only "good" reason to violate the LSP (Liskov
Substitution Principle) is to allow covariance.
2. You cannot have in your programming language all three of
the following language features: static type-checking,
covariance, and subtype substitutability (a.k.a. O-O
polymorphism a.k.a. ad-hoc polymorphism a.k.a. existential
types). You can have at most 2 out of 3.
A more precise explanation of what i mean when i name each of
those three features is embedded in my "Four Reasons" article.
Regards,
Zooko
P.S. I hope none of the aforementioned O-O gurus take offense
at this rather curt criticism. I value their opinions rather
highly (else i would not name them "guru"), and i have been
very pleased that they have taken the trouble to respond to my
article.
P.P.S. I learned the 2-out-of-3 "riddle of type-systems" from
a paper entitled "Virtual Types Are Statically Safe", or maybe
from a related paper about extending Java with virtual types.
It was by a Scandinavian, i believe, whose name, paper, and URL
i have unfortunately lost. If anyone can remind me i would
appreciate it as i would like to keep those papers close at
hand!
-------
"Must it be assumed that because we are engineers beauty is not
our concern, and that while we make our constructions robust
and durable we do not also strive to make them elegant?"
-- Gustave Eiffel
Donald Fisk <···········@bt-sys.spamblock.bt.co.uk> writes:
> The differences between Java and Lisp/Scheme are far more noticeable
> than anysimilarities, but there are at least a few Lispy things in
> Java: catch and throw, a tokenizer (similar to the ratom primitive
> that read is built out of, though it annoyingly scans "." as 0.0),
> garbage collection, and bignums. Was it Guy that got these included
> in Java, and was this the result of an attempt to make the language
> as Lisp-like as was politically acceptable (i.e. not very much)?
There's even an "almost-lambda" in Java (anonymous classes). Abysmal syntax,
of course, but at least you don't have to think up names for your closures.
Jens.
--
··········@acm.org phone:+49-7031-14-7698 (HP TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-14-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
In article <··················@lambda.ai.mit.edu>,
Olin Shivers <·······@lambda.ai.mit.edu> wrote:
>"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
>
>He works at Sun's East Coast lab. As far as I can tell, he's mostly working on
>Java-related technology -- a job for which a Scheme/Lisp background is rather
>helpful.
>
>I wouldn't describe him as wandering in the desert.
I would.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
Keith Wright <·······@tiac.net> writes:
> > BTW, does anyone know what happened to GLS? Now that TM is dead (or so
> > I've heard) he must be off wandering in the desert.
>
> Sun Microsystems, I believe. It's like the desert, only there's
> a water cooler and some comfy chairs and computers and...
...a hot cup of Java.
<http://java.sun.com/docs/books/jls/index.html>
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
From: Klaus Schilling
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <87u30hemac.fsf@ivm.de>
Matt Curtin <········@interhack.net> writes:
> Keith Wright <·······@tiac.net> writes:
>
> > > BTW, does anyone know what happened to GLS? Now that TM is dead (or so
> > > I've heard) he must be off wandering in the desert.
> >
> > Sun Microsystems, I believe. It's like the desert, only there's
> > a water cooler and some comfy chairs and computers and...
>
> ...a hot cup of Java.
Java sucks, it can't hold a candle to Scheme.
Klaus Schilling
Klaus Schilling <···············@home.ivm.de> writes:
> Java sucks, it can't hold a candle to Scheme.
Come on, Klaus, if you're going to write a program to post the same
thing every time someone mentions any language besides Scheme, can't
you at least make it come up with a snappier response?
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
From: Myche'jae-Bel
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <72geoh$pso@umbc8.umbc.edu>
In article <···············@gold.cis.ohio-state.edu>,
Matt Curtin <········@interhack.net> wrote:
>Klaus Schilling <···············@home.ivm.de> writes:
>
>> Java sucks, it can't hold a candle to Scheme.
>
>Come on, Klaus, if you're going to write a program to post the same
>thing every time someone mentions any language besides Scheme, can't
>you at least make it come up with a snappier response?
>
>--
>Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
Yeah, but which language did he write it in?
=)
(my bet's on Perl)
--
======================================== http://www.gl.umbc.edu/~mikeb =
Mike J. Bell \_O The above are my opinions.
UMBC Alumnus _/\_ finger ·····@gl.umbc.edu for my
·····@gl.umbc.edu / \_ PGP public key
From: Klaus Schilling
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <87u3043s4j.fsf@ivm.de>
·····@umbc.edu (Myche'jae-Bel) writes:
> In article <···············@gold.cis.ohio-state.edu>,
> Matt Curtin <········@interhack.net> wrote:
> >Come on, Klaus, if you're going to write a program to post the same
> >thing every time someone mentions any language besides Scheme, can't
> >you at least make it come up with a snappier response?
> >
> >--
> >Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
>
> Yeah, but which language did he write it in?
>
> =)
>
> (my bet's on Perl)
All lies. One doesn't need a program to do that.
Klaus Schilling
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
>
> BTW, does anyone know what happened to GLS? Now that TM is dead (or so
> I've heard) he must be off wandering in the desert.
>
Among other things, I'm sure:
The Java Language Specification
James Gosling, Bill Joy & Guy Steele
Addison-Wesley ISBN 0-201-63451-1
--
joe
Klaus Schilling wrote:
> > Lisp (sorta)
> > Scheme (duh)
> > T (duh*2)
> > ML (I think)
> >
> > and possibly:
> >
> > PLANNER (and $\mu$-PLANNER)
> > CONNIVER (? never seen it, so I'm guessing)
>
> Haskell
> Gofer
> Hope
> Miranda
> Caml
> Mercury
There's at least one other language worthy of mention, and that is False.
This isthe language with the second smallest compiler, of just one kilobyte
(the language
with the smallest compiler is Brainfuck, with just 240 bytes). False is a
stack based
language with similarities to Forth, but it supports lambda abstraction. See
http://dsse.ecs.soton.ac.uk/~wvo96r/false/index.html for more details.
> Klaus schilling
--
Le Hibou (mo bheachd fh�in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS."
-- Erik Naggum
From: Howard R. Stearns
Subject: Re: Languages based on the Lambda Calculus
Date:
Message-ID: <362CDBDA.68AD4188@elwood.com>
See the books, papers and related languages section of the ALU web site,
currently at http://www.elwood.com/alu/table/contents.htm
In particular, Lisp In Small Pieces has a pretty good Lambda Calculus
chapter.
Regarding abandoning general coursework in favor of CS:
Many of the best programmers I have come across were engineers,
particularly Naval Architects. (Disclaimer: I have a degree in N.A.)
WELL EDUCATED enginneers (as opposed to vocational/technical training),
and in paticular, those who study the design of complex things like
ships, are well versed in complexity, abstractions, mathematics, etc.
For example, the "design spiral", as opposed to "waterfal", was taught
formally to Naval Architects at least fifty years before its current
vogue in popular C.S.
One could make similar claims about great computer people who are
physicists (who are great at everything they do), authors, poets, gym
teachers, .....
The point is, don't think you are learning more by taking a narrower
range of study.
Also, I understand that Richard Gabriel's latest book ("patterns") might
offer some experience on wandering through academia and industry on the
way to retiring to the woods...
James A. Crippen wrote:
>
> I recently made the somewhat foolish mistake of selecting the topic for
> a term paper in a Language Concepts class thusly: "Programming Languages
> with Connections to the Lambda Calculus". The subtitle is, in proper
> Scheme style, "or \\ LAMBDA: the Ultimate Programming Language".
>
> The local libraries are rather lacking in this, as the only books I can
> find are:
> _The_Lambda_Calculus_ by Barendregt (which I've already read the edges
> off of), some topology books with interesting surface topologies, a
> crufty hardbound Interlisp manual, _Let's_Learn_Lisp_ by someone or
> other (Siklosky? IFRNAIBUTL), a VAXIMA manual, CLtL1 rebound with scotch
> tape, and _Simply_Scheme_. These do me no good as I already speak
> Scheme and Lisp and can parse and occasionally generate lambda calculus
> (taught myself, so I'm not exactly good at it).
>
> Then I did a search on publications outside MIT. That turned up
> woefully few that weren't too heavy and abstract for use.
>
> Help! I need names of languages related in some way to the lambda
> calculus. Direct and indirect are both admissible. Here are some I
> already know:
>
> Lisp (sorta)
> Scheme (duh)
> T (duh*2)
> ML (I think)
>
> and possibly:
>
> PLANNER (and $\mu$-PLANNER)
> CONNIVER (? never seen it, so I'm guessing)
>
> and those last two I can't find any decent papers on (found the
> $\mu$-PLANNER FM, but that doesn't give me any theory). There are some
> languages with indirect connections, but I'm not a language lawyer so I
> hesitate to make any guesses without sufficient reference material to
> back them up.
>
> After the list, some pointers to relevant data would be helpful. I need
> mostly language design and (some) implementation theory, hopefully from
> the minds of the authors. If I could put "personal communication" in
> any of my references I know I'd get brownie points for weird references,
> especially if it was with one of the language designers.
>
> The local U library is (thankfully) willing to do InterLibraryLoans with
> other libs in the nation. Otherwise I'd be sunk.
>
> (flamage 'rant)
> My eventual goal is to have a paper that makes all the other papers ever
> written for this class look somewhat pathetic in comparison. That's not
> a difficult goal because this university tends to churn out people who
> should have graduated with a degree in MIS (called "Computer Information
> & Office Systems" locally) and not CS. Many of the ones that don't
> graduate go on to exciting careers in the petroleum industry writing
> 20MB VB (the neu-COBOL) 'programs' to sort payroll data. Whee. I intend
> to go into research, and am consequently looked upon as insane. "Why do
> research when you can make 40 to 80k/yr writing VeeBee programs for big
> Oil?" Aargh.
>
> The most awful thing is that the CS program isn't even accredited. We
> lost two professors last year, thus narrowing down the department to one
> professor, one asst prof, and one adjunct with an office. And someone
> in the Math dept became chair of the Math Sciences which includes math,
> CS, and sadistics. And the university says they have to keep both
> professorial positions closed for a year each to see "if they are
> necessary for the continued operation of the department".
>
> I've decided to completely ignore all of the "General Education
> Requirements" in favor of taking all the offered CS and Math courses
> until I can't stand the school any further, then trying to go somewhere
> else on my raw knowledge and charm alone. Grad school or undergrad
> doesn't matter, just as long as some decent school will take pity on
> this hacker and offer me some work.
>
> I set my sights high tho. When the time is ripe I'll pack up and drive
> to Boston headed for you-know-where. Maybe if I get a job hacking UNIX
> with some Beantown area fly-by-night ISP I can spend my free waking
> hours in the AI lab doing things I shouldn't. Possibly someone will
> eventually take notice and take me under their wing. Otherwise I'll
> just have fun. If nothing happens there then I'll go to JHU, then CMU,
> then Indiana, then wherever, and I might end up at Stanford or
> somewhere. Doesn't matter. Just as long as I can come back in ten or
> twenty years with a couple MSs and a PhD, then retire as a consultant
> and hide in the woods here in Alaska. A log cabin, dish, and windmill
> farm are all I'll need. And maybe a llama or two.
> (flamage nil)
>
> The non flame part of the message is important. The flamage is (as
> usual) frivolous.
>
> advTHANKSance,
> cheers,
> james
Howard R. Stearns wrote in message <·················@elwood.com>...
>Regarding abandoning general coursework in favor of CS:
>
> Many of the best programmers I have come across were engineers,
>particularly Naval Architects. (Disclaimer: I have a degree in N.A.)
>WELL EDUCATED enginneers (as opposed to vocational/technical training),
>and in paticular, those who study the design of complex things like
>
The CS grads I have had the opportunity to interview for programming
postions in the last few years (imo) have had (very) poor math skills. Each
interviewee dutifully offered to bring samples of programs they had
written....I fell for this for awhile. Now I ask them to bring examples of
two generalized functions they have coded in the language of their choice
that will solve the following
1. air is being pumped into a large spherical ballon at a rate of 10
ft^3/min. How fast is the radius of the ballon increasing when the diameter
is 4 feet?
2. among all rectangles of a given area A, find the one with the smallest
perimeter.
T'is ashame why many develope temporay aphasia at this point of the phone
call. Though I have not had the opportunity to hire a "seasoned" lisp
programmer (or the budget) , I can say that ones I have had dealings with
had excellent math skill. (we have had to bring in a consultant or two to
help with numerical analysis bugs. when differentiations involve a trig
function the probabitility of profligate nosiy bits can be geometric as the
trig function approachs it's limits).
math guy and would be lisp programmer
rusty
From: John Atwood
Subject: Design Spiral, patterns, techniques from other fields
Date:
Message-ID: <70isti$6cc$1@news.NERO.NET>
In article <·················@elwood.com>,
Howard R. Stearns <······@elwood.com> wrote:
>
> Many of the best programmers I have come across were engineers,
>particularly Naval Architects. (Disclaimer: I have a degree in N.A.)
>WELL EDUCATED enginneers (as opposed to vocational/technical training),
>and in paticular, those who study the design of complex things like
>ships, are well versed in complexity, abstractions, mathematics, etc.
>For example, the "design spiral", as opposed to "waterfal", was taught
>formally to Naval Architects at least fifty years before its current
>vogue in popular C.S.
>
> One could make similar claims about great computer people who are
>physicists (who are great at everything they do), authors, poets, gym
>teachers, .....
>
>The point is, don't think you are learning more by taking a narrower
>range of study.
How can one do spiral design in Naval Architecture? For example: "Ok, now
we'll need to make the ship 3ft longer..." I'm thinking that software's
malleability is what makes spiral development possible.
On a more serious note, we have patterns from terrestrial architecture,
now design spiral from naval architecture; doesn't software need materials
rather than techniques; i.e. concrete and steel rather than the mud and
straw we're using now?
John
From: Jon Kaare Hellan
Subject: Re: Design Spiral, patterns, techniques from other fields
Date:
Message-ID: <yn4hfwyuz19.fsf@hyll.item.ntnu.no>
·······@bronze.CS.ORST.EDU (John Atwood) writes:
> In article <·················@elwood.com>,
> Howard R. Stearns <······@elwood.com> wrote:
> How can one do spiral design in Naval Architecture? For example: "Ok, now
> we'll need to make the ship 3ft longer..."
Believe me it happens.
Jon
--
Jon K. Hellan ············@item.ntnu.no
Div. of Telematics, Norw. U. of Science & Technology, Trondheim - Norway
From: Howard R. Stearns
Subject: Re: Design Spiral, patterns, techniques from other fields
Date:
Message-ID: <362E2006.C50C1A6E@elwood.com>
[WARNING: totally off subject for Lisp]
John Atwood wrote:
>
> In article <·················@elwood.com>,
> Howard R. Stearns <······@elwood.com> wrote:
> >
> > Many of the best programmers I have come across were engineers,
> >particularly Naval Architects. (Disclaimer: I have a degree in N.A.)
> >WELL EDUCATED enginneers (as opposed to vocational/technical training),
> >and in paticular, those who study the design of complex things like
> >ships, are well versed in complexity, abstractions, mathematics, etc.
> >For example, the "design spiral", as opposed to "waterfal", was taught
> >formally to Naval Architects at least fifty years before its current
> >vogue in popular C.S.
> >
> > One could make similar claims about great computer people who are
> >physicists (who are great at everything they do), authors, poets, gym
> >teachers, .....
> >
> >The point is, don't think you are learning more by taking a narrower
> >range of study.
>
> How can one do spiral design in Naval Architecture? For example: "Ok, now
> we'll need to make the ship 3ft longer..." I'm thinking that software's
> malleability is what makes spiral development possible.
I view the difference between software and other engineering disciplines
as being that it is easier/faster/cheaper to test the design with
something approaching a working model. BUT... there should still be a
design, which itself undergoes change. The waterfall and design spiral
models are attempts to describe that changing DESIGN process (as opposed
to a changing "end-product" process, which is a non-sequitor).
In ship design, the most basic and important parameters (length,
capacity, displacement,...) change often, sometimes radically, during
the design process. For example, the quintessential Mariner class cargo
ship is 563'-7 3/4" long x 76' wide x 44'-6" deep. The original
customer did not specify these dimensions, nor were they arrived at by
some a priori equation-solving. Instead, one guesses (from experience
and/or preliminary guestimating functions) what the initial parameters
should be, and then designs more of the ship in sufficient detail that
one can test the original estimates. One then changes the parameters as
necessarry and repeats -- hopefully converging on a solution.
Naval Architecture students are explicitly taught the different formal
design stages (conceptual, feasibility, preliminary, construction) as
well as the processes and meta-models that occur during them.
>
> On a more serious note, we have patterns from terrestrial architecture,
> now design spiral from naval architecture; doesn't software need materials
> rather than techniques; i.e. concrete and steel rather than the mud and
> straw we're using now?
>
> John
In article <·················@saturn.math.uaa.alaska.edu>,
"James A. Crippen" <········@saturn.math.uaa.alaska.edu> writes:
JAC> the topic for a term paper [...]: "Programming Languages with
JAC> Connections to the Lambda Calculus".
JAC> _The_Lambda_Calculus_ by Barendregt (which I've already read the
JAC> edges off of),
That's a rather impressive feat. How did you like the pictures?
Somewhat easier reading is a textbook by Gunter. I don't have it
handy, but I think it is something like
Carl Gunter
``Semantics of programming languages: structures and techniques''
You might find it helpful to read this before you get started on
research papers such as the one by Plotkin that Shriram mentioned.
Other lambda-calculi you might want to know about are Abramsky's `lazy
lambda-calculus' and a variety of linear calculi.
A related topic (but off-topic on these newsgroups) is the design of
type systems for lambda calculi. I liked the following introduction
very much (available online from http://www.luca.demon.co.uk):
@InCollection{cardelli:type-systems,
author = {Luca Cardelli},
title = {Type Systems},
booktitle = {CRC Handbook of Computer Science and Engineering},
year = 1997
}
Good luck,
J.
P.S. Hypatia is your friend.
http://hypatia.dcs.qmw.ac.uk/