HDTenEightyP/NetNews huggingface dataset:
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.lang.scheme
Subject: Re^2: random rant on random files
Date: 17 Aug 92 23:00:56 GMT
Organization: Microtek DSD, Hillsboro, OR

bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:

>I don't find this "store" idea obvious at all.  Does it live in memory
>or on the disk?  If on the disk, does that mean there is a redundant
>disk-to-disk copy when I finally use store->file?  If in memory, how
>do you handle gigabyte stores?

Sorry.  Let me amplify a bit.

The creation operations return a "store" object.  All store objects
are treated the same.  For files, the bits stay on the disk (mod
buffering).  STORE->FILE writes the contents of a store (the bits)
into a file.  If the store represents a file, then you are doing a
file->file copy.  If the store represents a slice of memory, you are
doing a memory->file copy.  You have full random, binary access to
store objects, so (STORE-REF-BYTE aStore 37) reads a byte from a file
or a memory location at "start"+ 37.

As stores are random, binary i/o, everything is mapped to positive
integers.  If you want to write a Scheme object (e.g. a vector or a
negative integer, etc.) it is up to you to do the representation
mapping. 

To map memory to a store: (MAP-STORE 100 200) returns a store with
a base address of 100.  (store-ref-byte thisStore 0) gives you the
byte at address 100+0 in your memory space.  Thus you can build a
structure mechanism on top of stores to get values of C structs,
Pascal records, whatever, by name.

You can also use stores which are really vectors unscanned by the
collector.  This is what MAKE-STORE returns.

If you have not guessed by now, stores are a pretty low-level
interface.  If done portable, however, this just happens to be a
higher-level interface than we have now.  I think that the abstraction
is useful.


So let me try again.

> Does it live in memory or on the disk? 

It does not matter to the user of the abstraction, but memory is
probably in memory and files are probably on disk (mod buffering).


> If on the disk, does that mean there is a redundant
>disk-to-disk copy when I finally use store->file? 

If you are doing a copy, where is the redundancy?


> If in memory, how do you handle gigabyte stores?

By doing *nothing* special {I assume bignums and linear addressing}.
I am not copying anything to create a store (just as opening a file
does not copy the file).


Please ask more questions where confused.
-Ken
From: rwk@silver.sbi.com (Richard W. Kreutzer Consultant)
Newsgroups: comp.lang.scheme
Subject: Re: R^4RS Authors Comments on Dylan
Date: 17 Aug 92 18:31:48 GMT
Distribution: comp
Organization: Olympus Software, Inc.

Reguarding Scheme OO and Dylan...

Since reading about the language Self, I have been impressed with the
advantages of a "classless" approach to object oriented programming.  Having
little or no direct experience with Self or any other classless OO language, I
was impressed by the clear and persuasive advantages of the classless approach
expressed by the authors of Self.

While Dylan's class system appears to be well designed, its inability to
disambiguate (next-method) on classes derived from multiple bases is a
significant problem (IMHO).  Dylan's "non-object" orientation, a concern
previously expressed in this thread, precludes one from calling/sending
methods to "self" (aka "this") without explicit reference to the desired
"self" object.  Moreover, I am not convinced that class based OO languages are
preferable to classless languages and would very much like to see a discussion
of a classless Scheme OO system (since I am not a fan of the "Smalltalk style"
syntax of Self).

Perhaps there has not yet been enough experience with classless languages to
make a fair comparison?
--

--
        Richard W. (Dick) Kreutzer
Net:    rwk@quark.sbi.com				CIS:	70702,2174
Voice:  +1(801)571-2446					FAX:	+1(801)571-2448
Mail:   Integra Software Corp.; 1378 Jasmine Avenue; Sandy, UT 84092 (USA)
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.scheme
Subject: Re: message passing vs. generic functions
Date: 18 Aug 1992 04:34:46 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <9208171954.AA05736@cambridge.apple.com> bill@cambridge.apple.COM ("Bill St. Clair") writes:
>I find the CLOS generic function approach to be advantageous to the
>SmallTalk and old Flavors message sending approach for everything but
>one important case: delegation. Sometimes you want to have an object
>that special cases a couple of operations, but sends most of them on
>to another object.

This is true.  However, in my experience, automatic delegation like this is
a dangerous practice, and perhaps it shouldn't be facilitated.

The problem is that new operations may be added without the knowledge of
the designer of the delegating class.  Perhaps this new operation should be
special cased, but since the class hasn't been updated, it will just pass
it on naively.

The Symbolics Genera stream system makes extensive use of such classes, and
it's pretty big mess.

If you have a fixed list of operations on a set of classes (as languages
like C++ force you to do) then you don't have the problem of unexpected
operations being added.  But then you don't need to implement delegating
classes by specifying just the special-cases; since the list of normal
cases is available you can define all the delegating operations explicitly
(yes, it's tedious, but you can define a macro to automate it).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.scheme
Subject: Re: random rant on random files
Date: 18 Aug 92 21:12:57 GMT
	<16ocv6INNl87@agate.berkeley.edu> <701@data.rain.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: kend@data.rain.com's message of 17 Aug 92 23:00:56 GMT

In article <701@data.rain.com> kend@data.rain.com (Ken Dickey) writes:

   The creation operations return a "store" object.  All store objects
   are treated the same.  For files, the bits stay on the disk (mod
   buffering).  STORE->FILE writes the contents of a store (the bits)
   into a file. [...]  As stores are random, binary i/o, everything is
   mapped to positive integers.  If you want to write a Scheme object
   (e.g. a vector or a negative integer, etc.) it is up to you to do
   the representation mapping.

It seems to me that stores are the usual binary streams, but that you
are required to give an offset (a "seek" address) with every
read/write operation.

Personally, I prefer the old-fashioned binary stream interface; it is
the natural interface to things that may or may not be random access
and that may or may not be bidirectional. Stores look too much like
binary arrays, and, to me, the interface does not clearly reflect the
costs of the underlying operations.

What is wrong with binary streams?

				Thomas.
Newsgroups: comp.lang.scheme
From: thinman@netcom.com (Technically Sweet)
Subject: Re: random rant on random files
Date: Thu, 20 Aug 92 17:52:16 GMT
Organization: International Foundation for Internal Freedom

jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>scm4a10 offers:

>  (file-set-position <port> <integer>)			procedure

Wouldn't that be (file-position! <port> <integer>)?

Mindless consistency is a virtue in this arena.

-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.lang.scheme
Subject: Re: R^4RS Authors Comments on Dylan
Date: 17 Aug 92 09:02:52 GMT
Organization: Department of Computer Science, U of Copenhagen

jmiller@crl.DEC.COM writes:

>o Dylan's use of generic functions, derived directly from CLOS, fit
>  into the language in a particularly elegant manner.  If the Scheme
>  community does decide to adopt a modest object system, we should
>  study Dylan's subset of CLOS to make an informed choice between this
>  approach and the more traditional object-dispatch mechanism.

I think the traditional object-dispatch mechanism is more in the
scheme style of using higher-order functions. When reading the Dylan
report, it seemed to me that the generic function mechanism was a hack
to make object oriented dispatch first order. Furthermore, method
selection occurs at application time, where it will occur at
class-creation time with the traditional method. This gives more
efficient dispatch. The only advantage I can see of the generic
function approach is that you don't need a field in the objects for
methods. This need, however, only be a single pointer to the class
definition.

	Torben Mogensen (torbenm@diku.dk)
From: dyer@eagle.sharebase.com (Scot Dyer)
Newsgroups: comp.lang.scheme
Subject: Re: random rant on random files
Date: 21 Aug 92 22:59:43 GMT
Reply-To: dyer@eagle.sharebase.com (Scot Dyer)
Organization: NCR/ShareBase Corporation

In Article 1737: (from Thomas M. Breuel)
>   >What is wrong with binary streams?
>
>   Nothing.  But Scheme is not a store description language (like C/C++),
>   and does not have a binary interface defined. [...]

>It is also trivial to build a store interface on top of binary
>streams. One question is what the language should provide. I'd prefer
>to see it provide binary streams, not stores, since I feel that binary
>streams are more general.

In the intrest of generality, it might be a good idea to implement 'streams' as
vectors of the code that should be used for various low-level operations, like
        #( write-object-to-stream
           read-object-from-stream
           get-position
           set-position
           close-stream
           user-slot )

On top of this 'stream' object could be built all of the functions being talked
about.  I like this solution since it provides utmost generality.  A 'stream
type' vector could be made to represent binary contents of memory*, another for
a local file, another for a remote file, etc.  The difference would be in how
the file was opened...

I'm sure that the fields listed above are incomplete and assume a more rigid
model of streams than scheme really needs, but more fields could be added.
Mostly this would mean adding to Scheme:

        1) A few 'open file' functions that provide the appropriate vectors.
           (And therefore the low-level 'slots' or 'functions' required for
           this, even if they're left anonymous)
        2) An abstracted set of file manipulating functions that will work
           with any of these files.
        3) A constructor for new stream-type-vectors (perhaps
           (stream-vector...)?)

Of course, any object-system added to scheme (if one ever comes along) should
be used to implement files instead of a simple vector...

Anyway, just my $.02 cents worth.

        -- Scot

--
* provided functions for converting from exprs to binary and vice versa...
Newsgroups: comp.lang.scheme
From: jeff@aiai.edinburgh.ac.UK (Jeff Dalton)
Subject: Re: R^4RS Authors Comments on Dylan
Organization: The Internet
Date: Fri, 14 Aug 1992 17:16:27 GMT

What will the rather favorable reaction to Dylan mean in practice?
When similar features from other languages (T, OakLisp, EuLisp,
Common Lisp) are mentioned there's usually considerable resistence.

-- jd
Newsgroups: comp.lang.scheme
From: bill@cambridge.apple.COM ("Bill St. Clair")
Subject: message passing vs. generic functions
Organization: The Internet
Date: Mon, 17 Aug 1992 20:57:07 GMT

>From: Barry Margolin <barmar@think.com>
>Subject: R^4RS Authors Comments on Dylan
>Message-Id: <16ii5eINNonl@early-bird.think.com>

>Regarding the notion of "smart objects" and message passing, we in the CLOS
>community have basically decided that this is an artificial and restrictive
>paradigm.  We believe that the essence of OO programming is class
>inheritance and dynamic function dispatching.  The notion of
>object->class->method-table is not necessary for understanding this; it's a
>useful implementation technique for methods that only specialize on one
>argument, but it's not the appropriate way to conceptualize things.  In
>particular, it breaks down completely when the choice of implementation
>technique is based on two parameters (consider output, where the effect is
>dependent on both the type of object being output and the type of output
>destination (ASCII terminal, window, or file)).

I hate to open Pandora's box, but since this mailing list is probably
not read by droves of Smalltalk weenies, I may be able to do so without
causing a 2 week mail flood. Wish me luck.

I find the CLOS generic function approach to be advantageous to the
SmallTalk and old Flavors message sending approach for everything but
one important case: delegation. Sometimes you want to have an object
that special cases a couple of operations, but sends most of them on
to another object. Neither CALL-NEXT-METHOD nor NO-APPLICABLE-METHOD
is a satisfactory solution to this problem, as each must be used on
a per generic function (or per generic function metaclass) basis and
the delegating object does not know or want to know the complete set
of operations likely to be performed on it. The MOP (as defined in
the AMOP) also cannot solve this problem as the only specializable
arguments to COMPUTE-EFFECTIVE-METHOD are the generic function and
the method combination object. None of the arguments is available.
Only by changing the way that effective methods are computed on a
system-wide basis is there a hope of providing delegation,
and this is likely to be difficult to do and non-portable even
with a standardized MOP.

Said more succinctly, the concept of object delegation is foreign to the
generic function paradigm. The former is object centric. The latter
is function centric. The function centric approach is more natural for
Lisp, but the object centric approach seems more natural to me for
systems of distributed objects.

Newsgroups: comp.lang.scheme
From: rolfl@karl.uio.no (Rolf Lindgren)
Subject: Re: going back to church
Organization: Institutt for Humanistisk Informatikk, Blindern, Oslo, Norway
Date: Thu, 13 Aug 1992 17:51:40 GMT

>   ;BTW I ran this code in MacScheme, so I KNOW it works!!!! At 
>   ;least it did before I sent it!!!!

Talking 'bout MacScheme: What's the latest version, and where can I order
it from?

Thank you,












--
       Rolf Lindgren           |       "The opinions expressed above are
       616 Bjerke Studentheim  |        not necessarily those of anyone"
       N-0589 OSLO 5           |           rolfl.lindgren@usit.uio.no
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.lang.scheme
Subject: Re: Initializing vector elements
Date: 19 Aug 92 13:15:13 GMT
	<MFX.92Aug19102656@lenin.cs.tu-berlin.de>
Reply-To: jinx@zurich.ai.mit.edu
Distribution: comp
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: mfx@cs.tu-berlin.de's message of 19 Aug 92 08:27:30 GMT

In article <MFX.92Aug19102656@lenin.cs.tu-berlin.de> mfx@cs.tu-berlin.de (lala) writes:

|   You are nearly right -- IMHO, the Right Way is to give the init
|   procedure the index of the element to create:
|
|	(define m (make-vector 10 (lambda (i) (make-vector 10 0))))
|
|   like, in,
|
|      (make-vector 10 identity) => #(0,1,2,3,4,5,6,7,8,9)
|

This procedure exists in certain dialects.  In MIT Scheme it is called
MAKE-INITIALIZED-VECTOR.
From: brent@ssd.csd.harris.com (Brent Benson)
Newsgroups: comp.lang.scheme
Subject: Re: R^4RS Authors Comments on Dylan
Date: 14 Aug 92 13:46:14 GMT
Organization: Harris Computer Systems

jmiller@crl.DEC.COM writes:

> o It is not possible to make a (reasonable) portable implementation
> of Dylan in Scheme without the addition of some form of weak pointer
> object.  

I'm not clear on why this is so.  Can someone elaborate?

Thanks,
Brent
--
Brent Benson                     brent@ssd.csd.harris.com
Systems Software Development
Harris Computer Systems
From: mfx@cs.tu-berlin.de (lala)
Newsgroups: comp.lang.scheme
Subject: Re: Initializing vector elements
Date: 19 Aug 92 08:27:30 GMT
Distribution: comp
Organization: Technical University of Berlin, Germany

In article <PK.92Aug19100516@talitiainen.cs.tut.fi> pk@cs.tut.fi (Kellom{ki Pertti) writes:
[...problems with make-vector...]
   Has there been discussion about what the second argument of
   make-vector should be? I would like to see make-vector to take a
   procedure that would be called for every element of the vector. Thus
   the example would be written as

     (define m (make-vector 10 (lambda () (make-vector 10 0))))

   This seems like a Scheme way of doing things. I know it is possibly
   too late to change it, but I thought I'd bring it up just for the sake
   of discussion.

   If anyone can prove me wrong by giving an elegant way of defining m
   within R4RS Scheme, I'll be delighted.

You are nearly right -- IMHO, the Right Way is to give the init
procedure the index of the element to create:

     (define m (make-vector 10 (lambda (i) (make-vector 10 0))))

like, in,

   (make-vector 10 identity) => #(0,1,2,3,4,5,6,7,8,9)

or,

   (make-vector 3 (lambda(x) (make-vector 3 (lambda (y)(if (= x y) 1 0)))))

=> #(#(1,0,0)
     #(0,1,0)
     #(0,0,1))

   --
   Pertti Kellom\"aki (TeX format)  #       These opinions are mine, 
     Tampere Univ. of TeXnology     #              ALL MINE !
	 Software Systems Lab       #  (but go ahead and use them, if you like)


(Just my humble contribution to creeping featurism)

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: Jerome Chan <yjc@po.cwru.edu>
Subject: Re: Why won't this work?
X-Xxmessage-Id: <A6BC0E3B2F01F063@b61539.student.cwru.edu>
X-Xxdate: Sat, 22 Aug 92 20:31:07 GMT
Organization: The Tofu Society of Singapore
X-Useragent: Nuntius v1.1.1d9
Date: Sat, 22 Aug 92 19:28:17 GMT

  Thanks to all the people who flooded my mailbox with the answer! It
seems that the book was using a variant of scheme. All I had to do was to
replace the [] with ()s.

  Once again, thanks to all who answered!

---
 The Evil Tofu ("I thought I knew the Mac ...")

"Sure or Not? Got or Not one? Aiyah! Why like that one! Terriblur lah!
Horrijible lah! Kisau one! Alamak! Gone Case Aleady!"
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.lang.scheme
Subject: Re^4: random rant on random files
Date: 19 Aug 92 16:48:54 GMT
Organization: Microtek DSD, Hillsboro, OR

bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:


>Okay, so what do I do if I want to write a new file from scratch?

The same old way.  Open a file, write to it (as a stream), close it.
The current store proposal does not address file extension.

>The part about unsigned-integers-only seems a little user-unfriendly
>to me.

This is a systems programming level.  An implementation can use it
to build higher-level interfaces which do representation mapping
(to/from binary) for you.

>I mean, how does someone write a bignum into a store?

Well you could do (number->string) and store the bytes.  I don't think
that there will be standard binary exchange representations soon
(although MIT Scheme seems to do a pretty good job here).  What I want
is to be able to do representation mapping that **does not depend on
the underlying Scheme's representations**.  [I also do low-level
systems programming, where fixed buffers are very useful (e.g. for an
I/O interrupt).]

>Alternatively, maybe every primitive type has to have an unambiguous
>binary representation the same as it has a print form, and instead of
>explicitly mentioning types you just leave that argument out and
>Scheme figures it out.  That would mean, though, tagging everything
>in the store with its type.

Again, the point is to have a baseline so that this can be done in a
portable manner.

>I'm feeling a little disorganized about this message, but it's because
>I'm really struggling to make sense of the whole idea.  I mean, files
>just feel very different from memory to me.  I know that at some level
>of abstraction they're the same, but they perform quite differently.
>I don't understand [I'm not being sarcastic] the principle of language
>design whereby symbols and strings are treated separately but files
>and memory are treated the same.

Well, it is a abstraction.  Its a bit like thinking of indexes of disk
storage blocks and the blocks they reference as a continuous stream of
characters called a "file", which is certainly a useful abstraction.
After all, why treat disk storage blocks differently?

-Ken
Newsgroups: comp.lang.scheme
From: pk@cs.tut.fi (Kellom{ki Pertti)
Subject: Initializing vector elements
Organization: Tampere Univ. of Technology, Finland.
Distribution: comp
Date: Wed, 19 Aug 1992 08:05:16 GMT

Yesterday, a friend of mine was bitten by the semantics of
make-vector. He wanted to make a matrix by creating a vector of
vectors. So he goes on to write

  (define m (make-vector 10 (make-vector 10 0)))

and gets what he expects:

 #(#(0 0 0 0 0 0 0 0 0 0) 
   #(0 0 0 0 0 0 0 0 0 0) 
   ...
   #(0 0 0 0 0 0 0 0 0 0))

Now he changes the element at 0,0 to 42, and is surprised because the
entire leftmost column has changed. Being a teacher, I have seen this
happen countless times before.

It is clear what has happened: all the rows of the matrix are really
the same row. What bothers me is that there really is no clean way of
building a matrix like the one intended.  I can think of two ways:
explicitely looping over the rows, or using list->vector. The first
one is clumsy at best, and the second one feels like a kludge to me

(let ((m (make-vector 10)))
    (do ((i 0 (+ i 1)))
	((= i 10) m)
      (vector-set! m i (make-vector 10 0))))

(list->vector (map (lambda (n) (make-vector n 0)) 
                   '(10 10 10 10 10 10 10 10 10 10)))

Has there been discussion about what the second argument of
make-vector should be? I would like to see make-vector to take a
procedure that would be called for every element of the vector. Thus
the example would be written as

  (define m (make-vector 10 (lambda () (make-vector 10 0))))

This seems like a Scheme way of doing things. I know it is possibly
too late to change it, but I thought I'd bring it up just for the sake
of discussion.

If anyone can prove me wrong by giving an elegant way of defining m
within R4RS Scheme, I'll be delighted.
--
Pertti Kellom\"aki (TeX format)  #       These opinions are mine, 
  Tampere Univ. of TeXnology     #              ALL MINE !
      Software Systems Lab       #  (but go ahead and use them, if you like)


--
From: wand@dec5120z.ccs.northeastern.edu (Mitchell Wand)
Newsgroups: comp.lang.scheme
Subject: Re: Binary representation
Date: 21 Aug 92 16:38:40 GMT
	<TMB.92Aug18171257@arolla.idiap.ch> <704@data.rain.com>
	<TMB.92Aug20181314@arolla.idiap.ch> <vy#nk3h.thinman@netcom.com>
Organization: College of Computer Science, Northeastern University

In article <vy#nk3h.thinman@netcom.com> thinman@netcom.com (Technically Sweet) writes:

   The ASN.1 for binary stream representation of trees gives
   most of what is needed.  It's the inter-layer encoder (sort of)
   for the OSI suite, and thus has that meaningless aura of 
   standards legitimacy which helps in promoting something
   new as a standard.  "Look!  It builds on previous standards!"

Pardon my ignorance, but could someone explain in a little more detail just
what ASN.1 is?

--Mitch 
--
Mitchell Wand
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115     Phone: (617) 437 2072
Internet: wand@flora.ccs.northeastern.edu          Fax:   (617) 437 5121
Newsgroups: comp.lang.scheme
From: birkholz@crl.dec.com (Matt Birkholz)
Subject: R4RS essential syntax and bindings
Organization: DEC Cambridge Research Lab
Distribution: comp
Date: Wed, 19 Aug 1992 21:07:15 GMT

Before I scan through R4RS for the spec'd essential syntax and bindings, I
thought I'd ask on comp.lang.scheme: If anyone has such a list, in any
useful form, please let me know.  Thanks.
--
Matt Birkholz						Cambridge Research Lab
birkholz@crl.dec.com		<DARWIN><		Digital Equipment Corp.
Newsgroups: comp.lang.scheme