HDTenEightyP/NetNews huggingface dataset:
From: Scott_Fahlman@sef-pmax.slisp.cs.cmu.EDU
Newsgroups: comp.lang.scheme
Subject: Re: scheme/dylan (was Compilation on SPARC)
Date: 11 Oct 92 06:33:36 GMT
Organization: The Internet


    Dylan is aimed at developing 'real' applications, so the burden on 
    scheme is now reduced.  I hope Dylan catches on.  Mail to info-dylan
    from Rob MacLachlan indicates that a high performance Dylan implementation
    is being developed at CMU.  Given the CMU role/experience with Common Lisp
    and the possible efficiency of Dylan,  I am greatly looking forward to this.
    
I'd better clarify this before the rumors get out of control.  Rob
MacLachlan somewhat overstated the situation in his earlier note.  We in
the CMU Common Lisp project are very much interested in Dylan, but right
now we're engaged only in some preliminary exploration and some kibitzing
on the language design.

We *hope* to mount an effort that will, among other things, produce a
widely available, high-performance implementation of Dylan using much of
the technology that is currently in our Python compiler for Common Lisp
(plus maybe some new tricks).  However, this depends on our ability to put
together the funding and other resources to support such an effort.  We
think that this should be possible, but it is by no means certain at this
point.  We'll let people on this list know when and if our project becomes
more than an exploratory bootleg effort.

We are greatly looking forward to this as well.  I think it culd help Dylan
to "catch on" in several important niches.  I hope it works out that way.

-- Scott
===========================================================================

Scott E. Fahlman
CMU Common Lisp Project (fearless leader)
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu
Newsgroups: comp.lang.scheme
From: matt@volga.Berkeley.EDU (Matt Wright)
Subject: Scheme for the Macintosh
Organization: University of California, at Berkeley
Date: Thu, 15 Oct 1992 04:49:24 GMT

I need an implementation of Scheme for the Mac.  I'm going to use it to
write educational tools like a visual expression evaluator, so it needs to
have lots of fancy Macintoshy windows stuff.  (E.g., you click on an open
parenthesis to select that entire expression, then double click on it to
evaluate that expression, etc.)

Also, we're going to use the same Scheme to teach the class.  So it needs to
be r4rs (or at least r3rs) compliant.

I'm thinking of using MacScheme and Toolsmith, but I'd prefer a free Scheme
so that students can run it at home.  How are SCM and Pixie Scheme in terms
of interfaces to the Mac windows stuff?

Thanks,
-Matt
Newsgroups: comp.lang.scheme
From: rpg@cs.tulane.edu (Robert Goldman)
Subject: Re: Compilation on SPARC
Reply-To: rpg@cs.tulane.edu (Robert Goldman)
Organization: Department of Computer Science, Tulane University
Date: Tue, 13 Oct 1992 16:59:28 GMT
Nntp-Posting-Host-[nntpd-2362]: clones


I just wanted to take a minute to amplify on my earlier remarks.
Most of the responses I have gotten so far have been of the form:

"I have been doing <foo> very successfully for a long time using
just the interpreter.  I don't think one needs a compiler."

I've been teaching an AI class in Scheme, and would just like to
allow my students to compile the often-called functions (making
search states, manipulating queues, etc.) when they produce their
final projects.  Also, since some of the students are graduate
students who will want to go on to do work on a more ambitious
scale, I would like them to get a sense of how incremental
compilation works.

Motivating my desire to give them experience with incremental
compilation is my discovery, teaching Scheme to third and fourth
year CS students, that the hardest thing is getting them to grok the
different programming practices which come from writing programs in
an incremental development environment.  I often find that willing
and non-computer-phobic people with less background in languages
like C and Pascal have less trouble.  Do any of you all have this
experience, too?

R
Newsgroups: comp.lang.scheme
From: kobler@informatik.tu-muenchen.de (Daniel Kobler)
Subject: symbols: upcase = downcase. WHY?
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Date: Tue, 13 Oct 1992 11:36:43 GMT
Distribution: comp.lang.scheme

hi all,

I'd like to ask the following question:

  WHY should 'WALL be the same as 'Wall? What is the reason for
  not distinguishing between upper and lower case letters in
  symbols?

I think the answer should not contain
      `... due to historical reasons ...' or something like this.

Please give me an insight into the benefits of converting all letters
either to lower or upper case.

-Daniel ][
--
Daniel Kobler                        kobler@kiss.informatik.tu-muenchen.de
 TU  Muenchen, Arcisstr.21,          "Once upon a time I had a good girl,
 8000 Muenchen 2, Germany             once upon a girl I had a good time."
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.lang.scheme
Subject: Re^2: Compilation on SPARC
Date: 13 Oct 92 23:21:03 GMT
Article-I.D.: data.719
Organization: Microtek DSD, Hillsboro, OR

rpg@cs.tulane.edu (Robert Goldman) writes:
>Most of the responses I have gotten so far have been of the form:

>"I have been doing <foo> very successfully for a long time using
>just the interpreter.  I don't think one needs a compiler."
...
>Motivating my desire to give them experience with incremental
>compilation is my discovery, teaching Scheme to third and fourth
>year CS students, that the hardest thing is getting them to grok the
>different programming practices which come from writing programs in
>an incremental development environment.  I often find that willing
>and non-computer-phobic people with less background in languages
>like C and Pascal have less trouble.  Do any of you all have this
>experience, too?

Yes, although much of this can be attributed to other reasons.  If one
has never used closures or higher order functions and has never built
high-level abstractions, there is a lot of learned `bad' behavior to
be overcome.  It is easier to learn new material than to unlearn old
habbits.

-Ken
From: anders@diku.dk (Anders Bondorf)
Newsgroups: comp.lang.scheme
Subject: Re: Scheme partial evaluator?
Date: 14 Oct 92 09:57:06 GMT
Organization: Department of Computer Science, U of Copenhagen

> I think I saw a message here describing a partial evaluator
> for Scheme.  I think somebody at SICS wrote it.
> 
> Anyway, I'd be interested to find out about it, and any
> other related Scheme program transformation techniques.

It may be the partial evaluator Similix (developed at DIKU,
Copenhagen, Denmark) you are referring to. Here is how to ftp Similix:

-----------------------------------------------------------------------------
	  ftp ftp.diku.dk

login:	  anonymous
password: <your full e-mail address>
	  binary
	  hash
	  cd misc
	  get Similix.tar.Z
	  bye
-----------------------------------------------------------------------------

To decode the file Similix.tar.Z, run

	uncompress < Similix.tar.Z | tar xvpf -

A directory named

	Similix

then appears. Now read the file README in the Similix directory.
-----------------------------------------------------------------------------

Best regards,

Anders Bondorf

DIKU, Department of Computer Science
University of Copenhagen
Universitetsparken 1
DK-2100 Copenhagen \O
Denmark

e-mail: anders@diku.dk
Xref: sparky comp.lang.scheme:2372 comp.lang.functional:1247 comp.lang.lisp:2666
From: danvy@cis.ksu.edu (Olivier Danvy)
Newsgroups: comp.lang.scheme,comp.lang.functional,comp.lang.lisp
Subject: revised deadline for LASC special issue on continuations
Date: 14 Oct 92 22:29:24 GMT
Organization: Kansas State University
NNTP-Posting-Host: depot.cis.ksu.edu


                          Call for papers
         Lisp and Symbolic Computation Special Issue on Continuations

Papers are solicited for a special issue of the Lisp and Symbolic Computation
(LASC) on Continuations.  The notion of continuation is ubiquitous in many
different areas of computer science, including logic, constructive
mathematics, programming languages, and programming.  This special issue is a
followup to CW92 the Workshop on Continuations held in June in San Francisco
[between PLDI and LFP].  Suggested topics are: gaining a better understanding
of the nature of continuations; applications of continuations, and the
relation of continuations to other areas of logic and computer science.

Submissions are due Nov 1 1992.  Authors should submit a full paper plus
a 1-2 page extended abstract summarizing the main contributions.  Submissions 
will be prescreened by members of the CW92 program committee.  Papers passing 
the prescreening will undergo the normal review process.  

[Note the revised deadline is serious -- papers will be sent out
 for screening on Nov 2/3.]

Submissions should be sent to: 

Jan Zubkoff
Lucid Inc.
707 Laurel Street
Menlo Park, CA 94025
415/329-8400
jlz@lucid.com
Newsgroups: comp.lang.scheme.c
Subject: Re: 7.2 on the NeXT
From: max@Kolmogorov.gac.edu (Max Hailperin)
Date: 12 Oct 92 14:03:53
Reply-To: Max Hailperin <max@nic.gac.edu>
Organization: Gustavus Adolphus College, St. Peter, MN
In-reply-to: hardy@golem.ps.uci.edu's message of 9 Oct 92 18:00:26 GMTLines: 26

In article <HARDY.92Oct9110023@golem.ps.uci.edu>
 hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy)) writes:

   In article <199210062011.AA00961@miles.ircam.fr>
    Jonathan.Bachrach@ircam.fr (Jonathan Bachrach) writes:


      Does 7.2 run on the NeXT.  If not, any idea when it will?

   For the moment it's still:... Release 7.1.3 ...

I had already anwered Bachrach's question offline, but it looks like
I'd better do it online as well to neutralize Hardy's well-meaning
misinformation.

MIT Scheme 7.2 *does* run fine on the NeXT.  In fact, early versions
of Schematik came packaged with MIT Scheme 7.2.  The only reason why I
retreated to 7.1.3 for later versions of Schematik was because 7.2 had
"alpha test" status while 7.1.3 was officially released.  (I had been
using 7.2 rather than 7.1 before that point because the cache-flushing
code to accomodate the 68040 processor was originally in 7.2 only; as
of 7.1.3 it was back-ported into 7.1.)  7.2 worked fine on the NeXT
then and to my knowledge still does now.

Note that this doesn't address the (unasked) question of whether it is
preferable to use 7.1.3 or the latest 7.2.
Newsgroups: comp.lang.scheme.c,comp.lang.scheme
From: rpg@cs.tulane.edu (Robert Goldman)
Subject: Compilation on SPARC
Reply-To: rpg@cs.tulane.edu (Robert Goldman)
Organization: Department of Computer Science, Tulane University
Distribution: comp
Date: Fri, 9 Oct 1992 18:53:49 GMT
Nntp-Posting-Host-[nntpd-10036]: clones


Has anyone brought up the MIT Scheme native-code compiler on the
SPARC architecture?  If not, why not (I don't mean why haven't the C
Scheme developers done this --- obviously their needs are met by the
currently supported architectures --- but why hasn't anyone else)?
I would have thought it was a natural, given how many Suns there are
out there.  Is there something about this that would be particularly
difficult?  Or do you all just use Scheme->C or some such?

Thanks,
r
Newsgroups: comp.lang.scheme.c
From: esler@apollo.hp.com (Kevin Esler)
Subject: Seeking a port of MIT C Scheme to Apollo Domain/OS
Date: Thu, 15 Oct 1992 19:18:40 GMT
Distribution: comp
Reply-To: esler@apollo.hp.com
Organization: Hewlett-Packard Corporation, Chelmsford, MA

Has anyone ported C Scheme to Apollo boxes ?
--
--  
Kevin Esler //hewlett-packard/cso/nsg/std/clo/mll (MA Language Lab)
esler@apollo.hp.com   (508) 436-5979
From: hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy))
Subject: Re: 7.2 on the NeXT
In-reply-to: Jonathan.Bachrach@ircam.fr's message of Tue, 6 Oct 1992 20:11:01 GMT
Newsgroups: comp.lang.scheme.c
Organization: Department of Physics, UC Irvine, CA 92717-4575, USA
Date: 9 Oct 92 18:00:26 GMT


In article <199210062011.AA00961@miles.ircam.fr> Jonathan.Bachrach@ircam.fr (Jonathan Bachrach) writes:


   Does 7.2 run on the NeXT.  If not, any idea when it will?

For the moment it's still:

Scheme Microcode Version 11.59
MIT Scheme running under NeXT

Scheme saved on Thursday June 11, 1992 at 10:14:32 AM
  Release 7.1.3
  Microcode 11.59
  Runtime 14.104
  Schematik 1.1
  SF 4.20
  Liar (Motorola MC68040) 4.87

Schematik (a NeXTStep front end) is available from ftp.gac.edu.
To run scheme under emacs you need to rebuild emacs; version 
18.55.121 provided by NeXT is crippled and cannot run scheme as a
subprocess (same as in previous versions). 
--
Hardy 
-----
Meinhard E. Mayer,  Department of Physics, UC Irvine 
e-mail: hardy@golem.ps.uci.edu (preferred) or MMAYER@UCI.BITNET

Newsgroups: comp.lang.scheme.c
From: hanche@ams.sunysb.edu (Harald Hanche-Olsen)
Subject: Re: Seeking a port of MIT C Scheme to Apollo Domain/OS
Organization: University at Stony Brook, NY
Distribution: comp
Date: Sat, 17 Oct 1992 00:33:34 GMT

>>>>> On Thu, 15 Oct 1992 19:18:40 GMT, esler@apollo.hp.com (Kevin Esler) said:

Kevin> Has anyone ported C Scheme to Apollo boxes ?

I sent him my patches for this version:

Scheme saved on Thursday March 21, 1991 at 10:55:47 PM
  Release 7.1.0 (beta)
  Microcode 11.59
  Runtime 14.104
  SF 4.15

That seems like a loooong time ago, so I am not sure it still works
(or even if my patches are complete), so I didn't feel like posting.
However I will send them to anyone who wants them (but don't expect
a fast answer; I will be traveling for a couple weeks).

- Harald
Newsgroups: comp.lang.scheme
From: mfx@cs.tu-berlin.de (Markus Freericks)
Subject: Re: Compilation on SPARC
Organization: Technical University of Berlin, Germany
	<RWK.92Oct12144046@silver.sbi.com>
Distribution: comp
Date: Wed, 14 Oct 1992 09:21:57 GMT

In article <RWK.92Oct12144046@silver.sbi.com> rwk@silver.sbi.com (Richard W. Kreutzer Consultant) writes:
   In article <BvxAwM.DKw@cs.psu.edu> schwartz@roke.cs.psu.edu (Scott Schwartz) writes:
      rpg@cs.tulane.edu (Robert Goldman) writes:

	 why hasn't anyone else?

      My (quite possibly incorrect) observation is that, for most people's
      purposes, an interpreter adequate.  Most people who use scheme seem to
      be either

       1) doing research on programming languages.  unless they are researching
	  optimization techniques there is no point in writing a compiler at all,
	  and if they are, only one platform is necessary.
	[..]
   Maybe its a Catch 22.  Maybe more programmers would use Scheme to develop
   applications if there were procudtion quality compilers more readilly
   available. 
   [...]
   Dick

Indeed, this could be the case. I have used scheme to write a compiler
(and settled with SML, but that's another story) and tried, in that
order, ELK, MIT Scheme, and again, ELK. Why? because ELK has a
turnaround time two orders of magnitude better than MIT Scheme. If I
remember correctly, the read/compile times were about 1 second : 100
seconds. Of course, ELK can do this, compiling nearly nothing.

Scheme, being an interactive language, needs an interactive
environment, even for large programs. I would like to have an
interpreter/compiler pair, or a facility to have a #pragma at the
beginning of a file (or better, a function) to indicate that it ought
to be compiled.

The other point is, of course, that speed gained by compilation is
only half the goal. Isn't there a decent application stripper out
there? Scheme would gain a lot if i could say

 % cat foo.scm
 (write "hello, world")
 % sc foo.scm
 % ls -l f*
 -rw-r--r--  1 mfx            24 Oct 14 10:19 foo.scm
 -rw-r--r--  1 mfx          2498 Oct 14 10:20 foo*

After all, scheme has no "apply" function and no first-order
environments so that stripping an application should be possible.

Markus
-- 
Markus Freericks	| email: mfx@cs.tu-berlin.de	
TU Berlin Sekr.FR 2-2 	| phone: +49-30-314-21390
Franklinstr.28/29	| priv.: +49-30-872523
D-1000 Berlin 10	|"Inertia makes the world go 'round."
Newsgroups: comp.lang.scheme
From: davidf@golem.uucp (David J. Fiander)
Subject: Reading material
Date: Fri, 16 Oct 1992 01:47:12 GMT

Well, I'm getting into scheme quite a bit now.  I bought and
read SICP years ago, but now that I have an interpreter
(scm4a12), I'm starting to play around.  The last time I used
LISP was a version on Interlisp on my Atari 800 (which tells
you how long ago that was!).

I'm looking for more to read about scheme.  Yigit's
bibliography is good, but I would like to know "If you could
only have one scheme book (besides 1178 or R^nRS), which would
it be."

The choices seem to be Eisenberg's _Programming in Scheme_,
Dybvig's _Scheme Programming Language_, or Springer and
Friedman's _Scheme and the Art of Programming_.

- David
Newsgroups: comp.lang.scheme
From: zilla@ccrl.nj.nec.COM (John Lewis)
Subject: scheme/dylan (was Compilation on SPARC)
Organization: The Internet
Date: Sun, 11 Oct 1992 05:53:33 GMT

> From: Scott Schwartz <schwartz@roke.cs.psu.edu>
> Subject: Compilation on SPARC
>
> rpg@cs.tulane.edu (Robert Goldman) writes:
>
>   why hasn't anyone else?
>
> My (quite possibly incorrect) observation is that, for most people's
> purposes, an interpreter adequate.  Most people who use scheme seem to
> be either
> 
>  1) doing research on programming languages.  unless they are researching
>     optimization techniques there is no point in writing a compiler at all,
>     and if they are, only one platform is necessary.
> 
>  2) teaching intro cs classes
> 
>  3) using scheme as an embedded command language.
> 
> Only a very small number of scheme developers seem interested in using
> scheme do to actual systems and application programming.  (If I'm
> wrong about that, post lots of messages here!)  I wonder if an
> advantage of Dylan will be that its user community will have different
> goals than the scheme community.

I agree with this.  There should be a language suitable
for programming language research and teaching the issues of
programming language design.  Such a language needs to be free to
change, and to adopt constructs which may not be efficient at
the present time, in the view of some (this is how I view scheme's
numerical system!).  These characteristics are the opposite of those
desired of a 'real' or 'utility' language, i.e., stability and efficiency.

Dylan is aimed at developing 'real' applications, so the burden on 
scheme is now reduced.  I hope Dylan catches on.  Mail to info-dylan
from Rob MacLachlan indicates that a high performance Dylan implementation
is being developed at CMU.  Given the CMU role/experience with Common Lisp
and the possible efficiency of Dylan,  I am greatly looking forward to this.

Although CL, scheme, and dylan should probably be considered as 
having more differences than e.g. C and Pascal, thanks to their macro
systems it should not be too hard to port moderate amounts of
code to Dylan when it becomes available.

j.p.lewis/nec c&c research
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.scheme
Subject: old DEC machines (what has this got to do with scheme?)
Date: 7 Oct 1992 18:25:40 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <TED.92Oct6110540@lole.nmsu.edu> ted@nmsu.edu writes:
>was wasted for no good reason.  i expect that everybody who ever used
>an pdp-8, or 11, or a decsystem 10, or 20 will have good reason to
>mourn before too long.

If you could enlighten me offline, I'm very curious to know just what
was so wonderful with those particular boxes of silicon and wires.
I've used a pdp-11 and decsystem 20 (or maybe a 10), and I couldn't
really see the wonderfulness in them.  (In fact, I was rather
underwhelmed by the 20.)  What was I missing?

David Chase
Sun
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.lang.scheme
Subject: Re: symbols: upcase = downcase. WHY?
Date: 15 Oct 92 14:11:48 GMT
Article-I.D.: chamarti.JINX.92Oct15091148
Reply-To: jinx@zurich.ai.mit.edu
Distribution: comp.lang.scheme
Organization: M.I.T. Artificial Intelligence Lab.

In article <1992Oct13.113643.4508@Informatik.TU-Muenchen.DE> kobler@informatik.tu-muenchen.de (Daniel Kobler) writes:

|   From: kobler@informatik.tu-muenchen.de (Daniel Kobler)
|   Date: Tue, 13 Oct 1992 11:36:43 GMT
|
|   hi all,
|
|   I'd like to ask the following question:
|
|     WHY should 'WALL be the same as 'Wall? What is the reason for
|     not distinguishing between upper and lower case letters in
|     symbols?
|
|   I think the answer should not contain
|	 `... due to historical reasons ...' or something like this.
|
|   Please give me an insight into the benefits of converting all letters
|   either to lower or upper case.

There are two reasons to make symbols case insensitive:

1: Variable names are case insensitive.

2: Program text is traditionally read/parsed with READ as an
s-expression.

It would be possible to construct a system in which symbols are case
sensitive (and therfore READ treats ``foo'' and ``fOo'' differently),
but variables are case insensitive by having EVAL (or compile, or
whatever) copy the s-expression canonicalizing variable names as they
are found, but this is a pain in the neck.

If your question is why variable names are case insensitive (rather
than data symbols), then there are two answers:

1: It is traditional in Lisp.

2: It is a religious issue.  Some people feel strongly one way, some
the other, and people can debate this point endlessly without
accomplishing anything.

Some languages do it one way, some do it the other way.
Newsgroups: comp.lang.scheme
From: kjdriese@vnet3.vub.ac.be
Subject: Algorithms & Datastructures in Scheme
Organization: The Internet
Date: Fri, 9 Oct 1992 15:32:05 GMT

As far as I can see in the list of schools using Scheme, we (Brussels Free
University) are the only ones using Scheme for a course in Algorithms &
Datastructures.

Most of the books on this topic have example programs written in Pascal or
Pascal-like pseudo-code. We do not know of any that use a Lisp-like
language. We are in the process of collecting and writing  examples in
Scheme on the following topics:

- Searching Alg. (in sorted, unsorted, lists, vectors, tree-structures...)
- Sorting Alg. (simple sorts, quicksort, mergesort, heapsort...)
- Linear Datastr. (lists, stacks, queues ...)
- Tree structures (binary search trees (with balancing strategies),
B-trees,
                   heaps, prefix-trees...)
- Strings (datastructures & matching alg.)
- Hashing
- Graphs

We would be very happy to receive any material, if possible documented.
Estimations of performance differences of one and the same algorithm,
implemented for lists vs. vectors, functional vs. destructive, are also
welcome.

We will compile the material into a course, which we will make publicly
available.

Karel Driesen, PROG (WE), VUB, Pleinlaan 2, 1050 Brussels, Belgium
Telephone:      (+32) 2-6413306
Facsimile:      (+32) 2-6413495
Email:  kjdriese@vnet3.vub.ac.be


Newsgroups: comp.lang.scheme
From: f88-mdj@byse.nada.kth.se (Mikael Djurfeldt)
Subject: eval
Reply-To: Mikael Djurfeldt <djurfeldt@nada.kth.se>
Organization: Royal Institute of Technology, Stockholm, Sweden
Distribution: comp
Date: Wed, 7 Oct 1992 19:35:39 GMT

"eval" is not described in the revised^4 report.
I wonder:
Is there any consensus on the behaviour of "eval"?
Is it ever going to be included in scheme?

Mikael Djurfeldt