[this is a re-post, as the original didn't seem to make it out.]
···@jpl.nasa.gov (Erann Gat) writes:
> So can you cite an example of how two applications can interfere with
> each other by using the same symbol purely as a data value?
Erann,
I'm just as curious as you as to what Rahul (or Erik or Kent) might
say to this question, but I thought that by trying to pose the
situation you ask for above, I might learn something additional about
Lisp from you (or them).
In this case, I believe what matters in the existence of the symbol
and it's identity. When I use the reader, I have it generate the
symbol 'EOF when it reaches the end of the file (rather than
signaling an exception.) Before I process the result of the read, I
check it for identity against the symbol 'EOF. [This is probably an
example of how to write C/Perl code in Lisp, since I'm a
newbie... style pointers from anyone are welcome...]
That's a pretty trivial example of purely symbolic processing, but
what if I had two different packages (one for working with network
streams and one for working with file streams), each of which returned
a function that read from the appropriate type of stream. Further
suppose that my code dispatches to one of the two packages depending
on a structured naming scheme (like URIs). What I get back is a
function that reads from either a socket or a file, but I don't know
which!
Now, I may want to treat the two differently, so it'd be nice to
have them return unique symbols so that if I get 'EOF from a socket I
can attempt to re-initiate the connection, while if I get 'EOF from a
file I can just clean up and go about my business. But unless I have
packages, I have to write my code so that they generate either
'SOCKET-EOF or 'FILE-EOF instead of just plain old 'EOF. Integrating
this code with code from other people could also cause obvious
name space collision problems.
Packages are nice [to me] because I can check for either
'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
otherwise.
Does that make sense? Am I doing something hopelessly naive?
-jon
--
------------------
Jon Allen Boone
········@delamancha.org
In article <··············@validus.delamancha.org>, Jon Allen Boone
<········@delamancha.org> wrote:
> [this is a re-post, as the original didn't seem to make it out.]
>
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > So can you cite an example of how two applications can interfere with
> > each other by using the same symbol purely as a data value?
>
> Erann,
>
> I'm just as curious as you as to what Rahul (or Erik or Kent) might
> say to this question, but I thought that by trying to pose the
> situation you ask for above, I might learn something additional about
> Lisp from you (or them).
>
> In this case, I believe what matters in the existence of the symbol
> and it's identity. When I use the reader, I have it generate the
> symbol 'EOF when it reaches the end of the file (rather than
> signaling an exception.) Before I process the result of the read, I
> check it for identity against the symbol 'EOF. [This is probably an
> example of how to write C/Perl code in Lisp, since I'm a
> newbie... style pointers from anyone are welcome...]
>
> That's a pretty trivial example of purely symbolic processing, but
> what if I had two different packages (one for working with network
> streams and one for working with file streams), each of which returned
> a function that read from the appropriate type of stream. Further
> suppose that my code dispatches to one of the two packages depending
> on a structured naming scheme (like URIs). What I get back is a
> function that reads from either a socket or a file, but I don't know
> which!
>
> Now, I may want to treat the two differently, so it'd be nice to
> have them return unique symbols so that if I get 'EOF from a socket I
> can attempt to re-initiate the connection, while if I get 'EOF from a
> file I can just clean up and go about my business. But unless I have
> packages, I have to write my code so that they generate either
> 'SOCKET-EOF or 'FILE-EOF instead of just plain old 'EOF. Integrating
> this code with code from other people could also cause obvious
> name space collision problems.
>
> Packages are nice [to me] because I can check for either
> 'SOCKET::EOF or 'FILE::EOF when I have to, but just get by with 'EOF
> otherwise.
>
> Does that make sense? Am I doing something hopelessly naive?
Yes, that makes sense (to me, now). No, I don't think you're doing
anything "hopelessly naive."
However, I'd like to point out something I think is important:
> Now, I may want to treat the two differently
That, it seems to me, is the heart of the matter: two applications, both
use the same symbol, results from both applications are sent through some
data path after which it is no longer possible to distinguish their
source, but you nonetheless want to treat the two symbols differently. In
such a situation, packages solve the problem, and environments don't.
However, IMO (and I would like it noted that this is the first time I have
taken any sort of position in this discussion) it is not clear (at least
to me) how realistic that situation really is. You say that you "may"
want to treat the two differently without being specific about the
reason. I submit that this is because it's not so easy to construct a
realistic situation where you would want to make such a distinction. In
fact, in most cases you send data from two sources through a single data
path precisely because you don't care, nor do you want to care, where the
data came from. If you really had a good reason to distinguish
stream::eof and file::eof that same reason might have led you not to
conflate the two data paths in the first place. There's no way to know
without a more concrete example.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> That, it seems to me, is the heart of the matter: two applications,
> both use the same symbol, results from both applications are sent
> through some data path after which it is no longer possible to
> distinguish their source, but you nonetheless want to treat the two
> symbols differently. In such a situation, packages solve the problem,
> and environments don't.
It seems to me that this is the essence as well.
> However, IMO (and I would like it noted that this is the first time I
> have taken any sort of position in this discussion) it is not clear
> (at least to me) how realistic that situation really is.
So noted (by me). I also tried to construct as realistic a
situation as I could, given that I'm new at CL (between 1000-3000
lines of code written to date, given refactoring work) and haven't
actually done anything like what I brought up below (yet).
> You say that you "may" want to treat the two differently without being
> specific about the reason. I submit that this is because it's not so
> easy to construct a realistic situation where you would want to make
> such a distinction. In fact, in most cases you send data from two
> sources through a single data path precisely because you don't care,
> nor do you want to care, where the data came from. If you really had
> a good reason to distinguish stream::eof and file::eof that same
> reason might have led you not to conflate the two data paths in the
> first place. There's no way to know without a more concrete example.
I agree. I was not intending to speak solely from experience, but
was speculating on what I may want to do in the future. :-)
I imagine having some streams that are complete once you reach the
end [such as those you get from (make-string-<direction>-stream)],
while there are others that might be "restartable" [such as
concatenating several files together into a single input stream, or
re-establishing a network connection that has timed out.] But, this
needs to be more clearly thought out before I can make a case that
it's useful...
-jon
--
------------------
Jon Allen Boone
········@delamancha.org