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

[Hoehle, Joerg-C. <Joe...@t-...>]

Sam wrote:
>> * Honorable Arseny Slobodjuck <am...@ic...> 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