Subject: [clisp-list] Re[4]: Separate Unix error stream keyword for ext:run-shell-comma nd

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Jun 10 08:14:04 2003

Sam wrote:
>> * Honorable Arseny Slobodjuck <[email-masked]> writes:
>> No! It's just the value return method. LAUNCH initializes 
>(second half
>> of initialization) pipe-stream, then the user works with it.
>> 
>> (setf stream (make-pipe-input-stream))
>> (launch ... :output stream) ;initializes stream
>> (read stream)
>
>what if the user tries to read from stream before launch inits it?!
Exactly! Excellent question.

>(launch ... :output (:stream :element-type ...))
>is so much cleaner!

I agree with this. The conceptual driving force (for me) behind this is functional programming (FP) oriented thought, or the concept of "single assignment" known to compiler writers of imperative languages (and not only Single Assignment C, aka SAC).

I always try to write my code in such a way that after the initializing call, almost nothing needs to be modified. Many :read-only slots. Against typical OO (which I call "challenged OO" :).

This has many advantages
o no need to maintain state & check whether method x is callable in partly initialized state y.
o clear conceptual model (may need revision until one finally arrives at a such one)
o helps semi-automated program analysis
o easier to assess correctness

and disadvantages
o against C++ where one can hardly do anything useful in constructors unless extreme care is taken to protect the resources created, duplicating a lot of effort from the destructor, or involving C++ master level (cf. "exceptional C++" from Herb Sutter), which few people have.

Analysing the requirements, one usually recognizes this sort of transformation (in pseudo Java/C++/Python style) from
	init(parameters)
	o.set more parameters
	o.call

into either
	init(all needed parameters)
	o.call
or
	factory(parameters) -> o1
	o1(more parameters) -> o2 of a different class
	o2.call
Cf. uncurrying in FP.
In both cases the method cannot be called too early since the object doesn't exist yet.

Sam' suggestion of "the list (:STREAM :ELEMENT-TYPE ... :EXTERNAL-FORMAT ... :BUFFERED ...)" is equivalent to the second approach. In Lisp, o1 need not be materialized as an object.

Regards,
	Jorg Hohle

---

From: Arseny Slobodjuck <[email-masked]>
Date: Wed Jun 11 04:03:08 2003

Hi,

Wednesday, June 11, 2003, 1:13:04 AM, you wrote:

>>(second half of initialization) pipe-stream, then the user works
>>with it.
>>> 

> I agree with this. The conceptual driving force (for me) behind this
> is  functional  programming (FP) oriented thought, or the concept of
> "single assignment" known to compiler writers of imperative
> languages (and not only Single Assignment C, aka SAC).

Try to see it this way: streams and running external programs are
highly "non-FP" things. Launch is the function to run programs, not
creating streams, brewing beer and sending the mail. Streams are
'additional' to it, not essential. There are already closed streams. When
the program under pipe stream is finished, what do we have ? Exactly
the same - a pipe stream with invalid process handle. What if the user
tries to read from stream after it's finished ?

-- 
Best regards,
 Arseny