HDTenEightyP/NetNews huggingface dataset:
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.scheme
Subject: R5RS and macros
Date: 5 Jan 1993 15:55:27 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: anarres.cs.berkeley.edu

Forgive me if someone's already answered this, but I don't remember
seeing it:

Did the R5RS meeting clarify the status of that bizarre elephantine proposed
macro appendix from R4RS?  Or is that still up for discussion?

(It's the low-level part I find elephantine, btw; I can live with the
proposed extend-syntax.)
Newsgroups: comp.lang.scheme,comp.lang.c
From: russpj@microsoft.com (Russ Paul-Jones)
Subject: Re: applying or
Date: 06 Jan 93 00:20:44 GMT
Organization: Microsoft Corporation

In article <1993Jan1.184655.7023@viewlogic.com> josh@viewlogic.com (Josh Marantz) writes:
>
> [about short circuit evaluation of && and || (C syntax)]
>
>I was sort of glad to move to C/Scheme, where this short-circuiting
>was guaranteed, although I never thought about the compiler
>optimizations that the short-circuit guarantee prevents!  Would it be
>legal for a C or Scheme compiler to avoid the short-circuiting if it
>could prove there were no side effects involved, and if it looked like
>a fruitful optimization?

I can't speak for the Scheme language, but side effects are not the 
only problem in C; short circuit evaluation is often used to 
prevent "bad" runtime behavior.

In the subprogram:

if (a) && (b)
	c;

where a, b, and c stand for legal C expressions, the programmer 
may rely on the fact that b should only be evaluated if a is 
non-zero.  If a == 0, then b is allowed to be a "bad" 
expression (e.g. division by zero, dereference of an invalid pointer
or out-of-bounds array arithmetic, a call to a function with invalid 
parameters, arithmetic overflow) without affecting the behavior of 
the rest of the program.

Even if b is just a simple variable, if it is not initialized there 
may be problems (I can't find if Standard C categorizes access 
of an uninitizalized object as "harmless" or not).

So, there are some instances where this optimization might be made:

b = 4;
if (a*7)/3 > 100/a || b
	fred();

I would say that fred() may be called without evaluating the silly 
expression, even if a == 0.  But I would suspect that it would take 
a fairly clever compiler to safely find many of these instances.

On another note, it is good C programming practice to do a little 
optimization as a programmer in taking advantage of short-circuit 
evaluation.  For example, if the expressions a and b are really 
independent, without side effects, and of roughly equal cost to 
evaluate, but b == 0 is more likely than a == 0, I would write:

if (b) && (a)
	c;

I would probably not be too excited about a compiler that evaluated 
a first to find it non-zero most of the time.

If this has no relevance to Scheme, I'd suggest limiting followups 
to comp.lang.c.

>-- 
>Joshua Marantz                          You make my life and times
>Viewlogic Systems,                        a book of bluesy Saturdays
>josh@viewlogic.com                      And I have to choose...

-Russ Paul-Jones
russpj@microsoft.com
I have no connection with the compiler folk here, and I have no idea 
what our compiler does with these operators.  And, I'm not in any 
way speaking for my employer.
Newsgroups: comp.lang.scheme
Subject: Re: Amiga Scheme
From: Phillip_Coxon@equinox.gen.nz (Phill)
Date: 6 Jan 93 17:36:55 +1200
Organization: Equinox Networks
X-Newsreader: TIN [version 1.1 PL8]

Phill (Phillip_Coxon@equinox.gen.nz) wrote:

>I'm in pretty desperate need of an implementation of Scheme for the Amiga,
>preferably as close as possible to MacScheme. 

I have recieved the information I needed - many thanks to all those who
replied.

Phill
Newsgroups: comp.lang.scheme
From: marti@nugget.inf.ethz.ch (Robert Marti)
Subject: Re: applying or
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Wed, 6 Jan 1993 21:54:11 GMT

In article <1993Jan6.164736.10682@daffy.cs.wisc.edu>,
quale@spock.cs.wisc.edu (Doug Quale) writes in response
to an earlier article by me:
|> >Pascal as described in the 1st ed. of Jensen & Wirth did indeed specify
|> >that both the left _and_ right Boolean sub-expression of AND and OR must
|> >_always_ be evaluated.
|> 
|> Could you provide the page number that says this?  This directly conflicts
|> with my recollection that the User Manual and Report is completely silent
|> on this issue.  This is one of the Report's several bugs, but it was
|> pretty good for its time.
|> 
|> In a quick scan of the second edition (the one I had handy, but I can
|> get the first edition from the library) I couldn't find anything.  My
|> understanding is that short-circuit evaluation is compatible with the
|> requirements of the User Manual and Report, but is not required.  Many
|> early Pascal compilers didn't do short-circuit evaluation, and ultimately
|> many used the CDC implementation from ETH as the final arbiter on the
|> ambiguities in the definition.  (This was clearly less than ideal.)

Ahem.  I think you're pretty much correct here.  I couldn't find anything
in the 2nd Edition of J&W either, although I didn't search extensively.
(Interestingly enough, I had absolutely no problem to find the relevant
stuff in the "Report on the Programming Language Modula-2" contained in
N. Wirth, "Programming in Modula-2", 3rd, Corrected Ed., Springer, 1985,
where it says on p. 153:  "p OR q means 'if p then TRUE otherwise q' and
p AND q means 'if p then q otherwise FALSE'".)

However, Wirth himself assumed that Pascal implementations would always
evaluate both Boolean sub-expressons as can be seen e.g. in his Pascal
code in the 1st edition of "Algorithms and Data Structures".
Example:
  if p <> nil then
    if p^.key = x then
      begin
        (* do something here *)
      end

-- 
Robert Marti                    |  Phone:    +41 1 254 72 60
Informationssysteme             |  FAX:      +41 1 262 39 73
ETH-Zentrum                     |  E-Mail:   marti@inf.ethz.ch
CH-8092 Zurich, Switzerland     |
Newsgroups: comp.lang.scheme
From: thinman@netcom.com (Technically Sweet)
Subject: Scheme type checking
Organization: International Foundation for Internal Freedom
Date: Wed, 6 Jan 1993 21:27:20 GMT

A deeper issue here is that in Scheme, the truly
interesting types are not the defined ones but
list structures which you define.  I would like
to have a list structure grammar, for example:

	List of pairs:			(list (atom? . atom?) '*)
	List of (number . string):	(list (number? . string?) '*)

And a routine which takes the grammar and an argument list
and returns #t/#f for legality.  Better yet, I'd like to
receive an error diagnostic (given the latter grammar):
	
	'((3 . "a") (4 . "b") ("c" . "d")) -> '(1 1 0 0)
	
which shows the list-walk necessary to find the erroneous
car or cdr location.

A grammar for tree structures would be more complex than the one above.
I have no idea how to do a grammar for self-referential lists.

Is something like this available for Common Lisp or Scheme?

-- 

Lance Norskog
thinman@netcom.com
Data is not information is not knowledge is not wisdom.
From: dyer@airplane.sharebase.com (Scot Dyer)
Newsgroups: comp.lang.scheme
Subject: Re: applying or
Date: 4 Jan 93 19:02:58 GMT
Reply-To: dyer@airplane.sharebase.com (Scot Dyer)
Organization: NCR/ShareBase Corporation

From: manis@cs.ubc.ca (Vincent Manis)
///
/// In article <1992Dec31.181545.19917@sharebase.com>
/// dyer@airplane.sharebase.com (Scot Dyer) writes:
/// >Even in Algol, implicit delayed evaluation of procedure parameters was
/// >allowed -- a scary coincidence, yes? :)
/// [...]
/// Er, yes, and if you want to know the truth about `call-by-name', read
/// Don Knuth's article `Algol 60 Confidential', which appeared in CACM
/// sometime around '68. Name parameters and own[*] variables were ideas which
/// were very elegant indeed; the only problem with them was that they
/// couldn't be implemented efficiently (or at all, as in the case with own
/// array variables with dynamic bounds). I'm a great fan of elegance, but I
/// like my programs to run at speeds somewhat faster than glacial, too.

Most original ideas contain flaws like this that people don't see until they
write perverse procedures like your "foo"  LISPs mis-use of NIL might be
irritating, but compare it to the FORTRANs that were availible at the time
and the flaw seems quite minor.

I don't believe either own variables or named parameters interact with delay-ed
evaluation of procedure parameters (like in "if" or... see subject: line),
though.  It is a nice perversity for Algol fans, though.  :)

/// [*] Own variables were Algol 60's counterpart of statics. The problem
/// was that own variables were first class, which led to things like
/// 
///   procedure foo(i);
///      integer i;
///   begin
///      own integer a[i];
///      integer j;
///      if i < 10 then
///         for j := 1 to i do
///            read(a[j]);
///      else
///         a[11] := a[12];
///   end;
/// 
///   foo(9);  foo(12); foo(9); foo(12);
/// 
/// It really helps when designing a programming language to be able to
/// attribute a meaning to all legal programs!

Or to know exactly which programs should be considered illegal.  I don't think
context-free description is really that valuable for semmantics... As the
above procedure demonstrates.
From: lward@husc11.harvard.edu (Lester Ward)
Newsgroups: comp.lang.dylan
Subject: Re: This newsgroup has _nothing_ to do with musician Bob Dylan...
Date: 12 Jan 93 23:07:13 GMT
Article-I.D.: husc.lward.726880033

tuc@calico.cs.wisc.edu (Brian A. Cole) writes:
>  Even so, I don't think exploring the Dylan language
>or subscribing to this newsgroup will give you insights into the man or
>his music.

I don't know about that.  Interconnectedness of all things and all that.

Anyway, just how much like LISP is Dylan?

Wordman
Newsgroups: comp.lang.dylan
From: dmanning@cwis.unomaha.edu (Dave Manning)
Subject: Re: This newsgroup has _nothing_ to do with musician Bob Dylan...
Organization: University of Nebraska at Omaha
Date: Wed, 13 Jan 1993 00:01:17 GMT

tuc@calico.cs.wisc.edu (Brian A. Cole) writes:

>Dylan is a computer language designed by Apple-Cambridge.  It supposedly
>stands for DYnamic LANguage, but I can't help but think they had our
>friend Bob in mind.  Even so, I don't think exploring the Dylan language
>or subscribing to this newsgroup will give you insights into the man or
>his music.

Hey! Let's not forget poet Dylan Thomas as a potential allusion, who wrote
"The Lovesong of J. Alfred Bedrock" (or was that "Prufrock"? ;-). And I don't 
think we can eliminate Dylan from "Beverly Hills, 90210".

I'm very ill.

Dave
:-)
 
--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::  "What I have to say is unsaid;			Dave Manning	     ::
::    what I have to do is undone..."		dmanning@cwis.unomaha.edu    ::
:::::::::::::::::--Red House Painters::::::::::::::::::::::::::::::::::::::::::
Newsgroups: comp.lang.dylan
From: ses@sunSITE.unc.edu (Simon Spero)
Subject: Re: Fast generic function dispatching?
Keywords: generic-functions dispatching
Organization: University of North Carolina, Chapel Hill
Date: Wed, 13 Jan 1993 02:14:47 GMT

In article <1993Jan12.210144.28757@nntpd.lkg.dec.com> mjg@ktbush.ogo.dec.com (Michael J. Grier) writes:
>
>   Can someone either discuss, or post references to, techniques for
>implementing fast generic function method dispatching?  The techniques
>implied by the Dylan manual sound like for every invocation of a generic
>function you have to first filter through all the methods to find a list
>of possible methods which match the parameters, and then sort them, keeping
>the list around, in case a method decides it wants to invoke the next least
>generic method.

There are many techniques for reducing the cost of generic function dispatch;
the main ones I can think of are: caching various combinations of arguments,
type inference, and making several copies of a block of code, each specialised
for a different type.

I've got a few references on my desk: here at home I have

TICLOS: An implementation of CLOS for the explorer family
Patrick H Dussud, Lucid INC
OOPSLA '89

Fast Dispatch Mechanisms for Stock hardware
John R Rose, Sun Microsystems
OOPSLA '88

The latter paper is a very good summary of issues and techniques

Simon
-- 
Hackers Local 42- National Union of Computer Operatives, Chapel Hill section
------------------------------------------------------------------------------
"Arise you users of compression, though the   | WAIS/Z39.50 spoken here
tarfiles hold you down" - The Internetworkale | DoD #612 | Tel: +1-919-962-9107
From: secrist@msdsws.enet.dec.com (Strong datatypes for weak minds.)
Newsgroups: comp.lang.dylan
Subject: Obtaining a Dylan Manual from Apple
Date: 12 Jan 93 16:45:32 GMT
Organization: Digital Equipment Corporation


	Is Apple still distributing Dylan manuals from the
	dylan-manual-request@cambridge.apple.com address ?

	I've made several requests and never got one, although
	friends I passed the news along to have already
	received theirs.

	Regards,
	rcs

Newsgroups: comp.lang.dylan
From: trimble@ph-meter.beckman.uiuc.edu (Chris Trimble)
Subject: Re: This newsgroup has _nothing_ to do with musician Bob Dylan...
Organization: University of Illinois at Urbana
Date: Tue, 12 Jan 1993 22:18:34 GMT

tuc@calico.cs.wisc.edu (Brian A. Cole) writes:

>As a side-effect of owning the first post to comp.lang.dylan (at least
>in my corner of the world), I'm getting lots of email from people who
>think this newsgroup is somehow related to musician/philosopher/genius
>Bob Dylan.

>I'm not flaming these people -- there's nothing wrong with a little
>spurious email now and again -- but I thought I might as well clear
>this up.

 You must admit, though. Bob Dylan certainly has a language of his own.

 Unsubscribing after this post,

   - Chris

--
Chris Trimble	         | "'Villians!' I shreaked, 'dissemble no more! I admit
B.I. Systems Services    | the deed! - tear up the planks! - here, here! -it is
chris1@uiuc.edu          | the beating of his hideous heart!'"   - Edgar A. Poe
Newsgroups: comp.lang.dylan
From: mjg@ktbush.ogo.dec.com (Michael J. Grier)
Subject: Fast generic function dispatching?
Keywords: generic-functions dispatching
Reply-To: mjg@ktbush.ogo.dec.com (Michael J. Grier)
Organization: Digital Equipment Corporation
Date: Tue, 12 Jan 1993 21:01:44 GMT


   Can someone either discuss, or post references to, techniques for
implementing fast generic function method dispatching?  The techniques
implied by the Dylan manual sound like for every invocation of a generic
function you have to first filter through all the methods to find a list
of possible methods which match the parameters, and then sort them, keeping
the list around, in case a method decides it wants to invoke the next least
generic method.

   This sounds slow, and it just seems to me that one of the goals of Dylan
was to provide for a large amount of static/compile-time optimization in
the framework of a dynamic environment.  I'm curious if someone has some
tricks up their sleeve for getting this to be able to occur in constant time.

------------------------------------------------------------------------
I'm saying this, not Digital.  Don't hold them responsibile for it!

Michael J. Grier                           Digital Equipment Corporation
(508) 496-8417                             mjg@ktbush.dec.com
Stow, Mass, USA                            Mailstop OGO1-1/E16
Newsgroups: comp.lang.dylan
From: ses@sunSITE.unc.edu (Simon Spero)
Subject: Re: This newsgroup has _nothing_ to do with musician Bob Dylan...
Organization: University of North Carolina, Chapel Hill
Date: Wed, 13 Jan 1993 01:59:35 GMT

In article <lward.726880033@husc.harvard.edu> lward@husc11.harvard.edu (Lester Ward) writes:
>tuc@calico.cs.wisc.edu (Brian A. Cole) writes:
>>  Even so, I don't think exploring the Dylan language
>>or subscribing to this newsgroup will give you insights into the man or
>>his music.

And how many methods must a function dispatch
Before it can collect to the can
The answer my friend is in the FAQ,
The answer is in the FAQ

Simon

-- 
Hackers Local 42- National Union of Computer Operatives, Chapel Hill section
------------------------------------------------------------------------------
"Arise you users of compression, though the   | WAIS/Z39.50 spoken here
tarfiles hold you down" - The Internetworkale | DoD #612 | Tel: +1-919-962-9107
From: misawa@physics16.berkeley.edu (Shigeki Misawa)
Newsgroups: comp.lang.dylan
Subject: Dylan info
Date: 12 Jan 93 11:53:22
Organization: U.C. Berkeley Physics Department
Distribution: na
Reply-To: misawa@physics.berkeley.edu
NNTP-Posting-Host: physics16.berkeley.edu



	FAQ of the year: Where can I get/find information on Dylan ?


Shigeki Misawa
UCB Physics Department
From: tuc@calico.cs.wisc.edu (Brian A. Cole)
Newsgroups: comp.lang.dylan
Subject: c.l.dylan overlap with Dylan mailing lists?
Summary: Should I unsubscribe from any of the Dylan mailing lists?
Date: 12 Jan 93 17:16:56 GMT
Organization: U of Wisconsin Madison - Computer Sciences


Now that comp.lang.dylan (finally) exists, can I safely unsubscribe
from the info-dylan and/or the dylan-builders mailing lists?  I find
newsgroups more convenient than mailing lists, but I wouldn't want to
miss anything.

brian
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~     _______    _____     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian A. Cole                 |_   _  |  |  ___|    Most people think disc golf
  tuc@cs.wisc.edu               | | | |__| |___     is a joke.    It is not.
  ...!uwvax!cs.wisc.edu!tuc     |_| |__________|    That gives us the element
                                                    of surprise.
From: choo@cs.yale.edu (Young-il Choo)
Newsgroups: comp.lang.dylan
Subject: Re: This newsgroup has _nothing_ to do with musician Bob Dylan...
Date: 13 Jan 93 02:36:15 GMT
Organization: Yale Univ Computics

In article <dmanning.726883277@cwis> dmanning@cwis.unomaha.edu (Dave Manning) writes:

> Hey! Let's not forget poet Dylan Thomas as a potential allusion, who wrote
> "The Lovesong of J. Alfred Bedrock" (or was that "Prufrock"? ;-). 

> Dave 

I don't know what Dylan Thomas wrote, but just for the record, the poem "The
Love Song of J. Alfred Prufrock" was written by T.S.Eliot.

-- Young-il
Newsgroups: comp.lang.dylan
From: sara@utstat.toronto.edu (Sara Margaret Gardner (jamess))
Subject: New Library
Organization: U of Toronto Statistics
Date: Tue, 12 Jan 1993 20:28:01 GMT

Ok. Now with all these recent tributes to my friend Bob, I did
notice that there are opening a new library in his honour down
in NY city. They call it the Bobleian.
Newsgroups: comp.lang.dylan
From: bengtb@stacken.kth.se (Bengt Baverman)
Subject: Bug in Thomas <deque> ?
Organization: Stacken Computer Club, Stockholm, Sweden
Date: Tue, 12 Jan 1993 23:17:08 GMT


I have been playing around with Dylan and Thomas a couple of days now, but I
cannot understand how to use <deque>. Why do I get this response from Thomas:
 
	? (define q (make <deque>))
 
	;Value: q
 
	? (push q 'foo)
 
	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...
 
	? (push q (singleton 'foo))
 
	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...
 
	? (push q 4711)
 
	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...
	
Is this me? Have I misunderstod Dylan or is this a bug in Thomas? 
 
I'm using the latest versions of Gambit/Macintosh and Thomas.
 
Bengt Baverman
bengtb@alex.stacken.kth.se
 
-- 
Bengt Baverman
bengtb@alex.stacken.kth.se
Newsgroups: comp.lang.dylan
From: tuc@calico.cs.wisc.edu (Brian A. Cole)
Subject: This newsgroup has _nothing_ to do with musician Bob Dylan...
Summary: ...so stop sending me email asking me if it is.  :-)
Organization: U of Wisconsin Madison - Computer Sciences
Date: Tue, 12 Jan 1993 19:57:04 GMT

As a side-effect of owning the first post to comp.lang.dylan (at least
in my corner of the world), I'm getting lots of email from people who
think this newsgroup is somehow related to musician/philosopher/genius
Bob Dylan.

I'm not flaming these people -- there's nothing wrong with a little
spurious email now and again -- but I thought I might as well clear
this up.

Dylan is a computer language designed by Apple-Cambridge.  It supposedly
stands for DYnamic LANguage, but I can't help but think they had our
friend Bob in mind.  Even so, I don't think exploring the Dylan language
or subscribing to this newsgroup will give you insights into the man or
his music.

For that sort of thing I'd recommend rec.music.dylan.

brian

Disclaimer:  I don't know anything about the newsgroup rec.music.dylan,
except that it exists, but it seems like the right place to point people.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~     _______    _____     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian A. Cole                 |_   _  |  |  ___|    Most people think disc golf
  tuc@cs.wisc.edu               | | | |__| |___     is a joke.    It is not.
  ...!uwvax!cs.wisc.edu!tuc     |_| |__________|    That gives us the element
                                                    of surprise.
Newsgroups: comp.lang.dylan
From: benjy@athena.mit.edu (Benjamin B Thomas)
Subject: Re: Obtaining a Dylan Manual from Apple
Organization: Massachusetts Institute of Technology
Date: Wed, 13 Jan 1993 00:52:07 GMT

In article <2387@sousa.tay.dec.com> secrist@msdsws.enet.dec.com (Strong datatypes for weak minds.) writes:
>
>	Is Apple still distributing Dylan manuals from the
>	dylan-manual-request@cambridge.apple.com address ?
>
>	I've made several requests and never got one, although
>	friends I passed the news along to have already
>	received theirs.
>
>	Regards,
>	rcs
>

	It took mine a long time to arrive (about 1 - 1.5 months,) but
it finally got here. Hang on, I'm sure it will come eventally.


              />    
             /<     Benjy Thomas    benjy@athena.mit.edu
     [\\\\\\(O):::<======================================-
             \<       (617) 225-7116  Baker House 116 
              \>
From: tad@wrq.com (Tad Marshall)
Newsgroups: comp.client-server
Subject: Re: NFS and RPC
Keywords: NFS,RPC
Date: 7 Jan 93 03:05:33 GMT
Organization: Walker Richer & Quinn, Inc., Seattle, WA
NNTP-Posting-Host: elmer.wrq.com

In article <1992Dec30.155939.13344@spectrum.xerox.com> weltman@adoc.xerox.com writes:
>
>  I followed the initial discussion in this group about RPC, TCP, and
>UDP with great interest. At about the same time, a friend did a series
>of benchmarks in a network of Sparcstation 2's, to compare the file
>transfer performance using TCP sockets, NFS (write to remote-mounted
>disk), and RPC using TCP. The files were large (around 2 MB or larger).
>RPC using TCP was slightly slower than straight sockets using TCP, as
>expected. What was surprising was that it was so slow to just do a
>large write to the open file descriptor of a remote mounted file.
>
>Why is NFS so slow?

NFS is "stateless", which means that each "write" from the client side
will result in an open/write/close on the server.  The opens/closes slow
it down quite a bit over the file-transfers you were comparing it to.

-- Tad
Newsgroups: comp.client-server