From: Raymond Toy
Subject: load from stream?
Date: 
Message-ID: <4nofn9lydi.fsf@rtp.ericsson.se>
In the CLHS, LOAD accepts a stream as well as a pathname.  In the case
of a stream

        load determines what kind of stream it is and loads directly
        from the stream.

How is it supposed to know what kind of stream it is?  Implementation
dependent?  What is *load-truename* and *load-pathname* supposed to be
bound to in case of a stream that is not attached to a file?

Ray

From: Janis Dzerins
Subject: Re: load from stream?
Date: 
Message-ID: <87elo4q1c3.fsf@asaka.latnet.lv>
Raymond Toy <···@rtp.ericsson.se> writes:

> In the CLHS, LOAD accepts a stream as well as a pathname.  In the case
> of a stream
> 
>         load determines what kind of stream it is and loads directly
>         from the stream.
> 
> How is it supposed to know what kind of stream it is?  Implementation
> dependent?

Why not?

> What is *load-truename* and *load-pathname* supposed to be bound to
> in case of a stream that is not attached to a file?

See the spec -- it's nil.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Raymond Toy
Subject: Re: load from stream?
Date: 
Message-ID: <4nk7xwn6y5.fsf@rtp.ericsson.se>
>>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:

    Janis> Raymond Toy <···@rtp.ericsson.se> writes:
    >> In the CLHS, LOAD accepts a stream as well as a pathname.  In the case
    >> of a stream
    >> 
    >> load determines what kind of stream it is and loads directly
    >> from the stream.
    >> 
    >> How is it supposed to know what kind of stream it is?  Implementation
    >> dependent?

    Janis> Why not?

I guess my point was that you can't portably LOAD a stream because you
need to know a lot about how an implementation interprets the stream.

    >> What is *load-truename* and *load-pathname* supposed to be bound to
    >> in case of a stream that is not attached to a file?

    Janis> See the spec -- it's nil.

The spec is hundreds of pages.  Can you say where?  It doesn't say in
the entry for load.

Ray
From: Tim Bradshaw
Subject: Re: load from stream?
Date: 
Message-ID: <nkjy9mcbxdl.fsf@davros.tardis.ed.ac.uk>
Raymond Toy <···@rtp.ericsson.se> writes:


> I guess my point was that you can't portably LOAD a stream because you
> need to know a lot about how an implementation interprets the stream.
> 

Well you can't portably LOAD a fasl file either...  if LOAD could be entirely
portably written then CL wouldn't be CL...

--tim
From: Janis Dzerins
Subject: Re: load from stream?
Date: 
Message-ID: <871yk4orjw.fsf@asaka.latnet.lv>
Raymond Toy <···@rtp.ericsson.se> writes:

> >>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:
> 
>     Janis> Raymond Toy <···@rtp.ericsson.se> writes:
>     >> In the CLHS, LOAD accepts a stream as well as a pathname.  In
>     >> the case of a stream
>     >> 
>     >> load determines what kind of stream it is and loads directly
>     >> from the stream.
>     >> 
>     >> How is it supposed to know what kind of stream it is?
>     >> Implementation dependent?
> 
>     Janis> Why not?
> 
> I guess my point was that you can't portably LOAD a stream because
> you need to know a lot about how an implementation interprets the
> stream.

Yes -- you can't load portably from stream which is not a
file-stream. The behavior of LOAD is implementation-dependent in this
case so you should not rely on this to work at all in all _conforming_
implementations.

I don't think you have to know "a lot" about it -- just whether it
works in some particular implementation, and if yes -- what is the
exact behavior (i.e. does it load only source/compiled format, or
maybe both, depending on whether the stream is character or binary or
whatever). (I just quickly checked the ACL documentation and could not
find this to be documented.)

>     >> What is *load-truename* and *load-pathname* supposed to be
>     >> bound to in case of a stream that is not attached to a file?
> 
>     Janis> See the spec -- it's nil.
> 
> The spec is hundreds of pages.  Can you say where?  It doesn't say in
> the entry for load.

Looks like this one is a misunderstanding of the spec on my side. I
read "At other times" here:

  During a call to load, *load-pathname* is bound to the pathname
  denoted by the the first argument to load, merged against the
  defaults; that is, it is bound to (pathname (merge-pathnames
  filespec)). During the same time interval, *load-truename* is bound
  to the truename of the file being loaded.

  At other times, the value of these variables is nil.
  ^^^^^^^^^^^^^^

as "in other cases". Bad me.

----

Now, after having a closer look at LOAD I'm sure it is meant to be
used on files/file-streams. I imagine cases when loading from stream
would be a nice thing to have nd the right thing to do (like
evaluating/compiling forms from emacs using a stream insetead of
temporary file). And I think it is not doable with LOAD but a
combination of READ, EVAL and COMPILE.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Raymond Toy
Subject: Re: load from stream?
Date: 
Message-ID: <4n1yk3n37j.fsf@rtp.ericsson.se>
>>>>> "Janis" == Janis Dzerins <·····@latnet.lv> writes:

    Janis> Raymond Toy <···@rtp.ericsson.se> writes:
    >> I guess my point was that you can't portably LOAD a stream because
    >> you need to know a lot about how an implementation interprets the
    >> stream.

    Janis> Yes -- you can't load portably from stream which is not a
    Janis> file-stream. The behavior of LOAD is implementation-dependent in this
    Janis> case so you should not rely on this to work at all in all _conforming_
    Janis> implementations.

Without knowing for sure, but I would expect that the necessary parts
are there, just not exposed to the user since load can obviously load
source files and fasl files.

    Janis> I don't think you have to know "a lot" about it -- just whether it
    Janis> works in some particular implementation, and if yes -- what is the
    Janis> exact behavior (i.e. does it load only source/compiled format, or
    Janis> maybe both, depending on whether the stream is character or binary or
    Janis> whatever). (I just quickly checked the ACL documentation and could not
    Janis> find this to be documented.)

CMUCL uses (used to, and will again soon) :contents to specify whether
the stream is a source or fasl file.

Oh well.  That's life.

Ray
From: Kent M Pitman
Subject: Re: load from stream?
Date: 
Message-ID: <sfwu1wzvm7t.fsf@world.std.com>
Janis Dzerins <·····@latnet.lv> writes:

> Now, after having a closer look at LOAD I'm sure it is meant to be
> used on files/file-streams. I imagine cases when loading from stream
> would be a nice thing to have nd the right thing to do (like
> evaluating/compiling forms from emacs using a stream insetead of
> temporary file). And I think it is not doable with LOAD but a
> combination of READ, EVAL and COMPILE.

I think in cases where it's impossible to do the right thing, it's 
reasonable for implementations that want to extend LOAD to accomodate
streams to just bind *LOAD-PATHNAME* and *LOAD-TRUENAME* to NIL.
This will cause some operations that try to operate on these values to
fail, but that's what they should do in that case--that's typically
what will happen if you use READ/EVAL/COMPILE, so you're no worse off.

An extension to CL which I recall asking for and did not get in the
ANSI CL design process is the ability to use COMPILE-FILE to a binary
stream and to load from a binary stream.  I think this would be quite
useful to the creation of things like databased compiled functions,
for example.