Nп/п : 61 из 93
 От   : redsk...@gmail.com                  2:5075/128        02 сен 23 01:45:16
 К    : All                                                   02 сен 23 11:47:01
 Тема : Common Lisp - stream designators
----------------------------------------------------------------------------------
                                                                                 
@MSGID:
<8a511544-26bb-4e20-b44b-a583134d4c80n@googlegroups.com> e89b2b63
@REPLYADDR redsk...@gmail.com
<redsky1066@gmail.com>
@REPLYTO 2:5075/128 redsk...@gmail.com
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<8a511544-26bb-4e20-b44b-a583134d4c80n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
 Stream designators are conveniences when creating source code. It
makes for compact expression.

 BUT: can (or should?) stream designators be used deeper down, as
entities resolved during actual evaluation?

Specifically wondering about SYNONYM-STREAM. 

 The [dynamic] variable of such a stream holds the value on which
an operation is to be performed. 

 If that variable is bound to an actual stream object, then
everything seems well-defined.

 But if that variable is bound to a STREAM DESIGNATOR, is this
well-defined? We have for instance the ambiguity of designator NIL (input vs
output).

So: 
 (1) are stream designators formally acceptable as values of the
variable for a SYNONYM-STREAM?

 (2) if they are not acceptable, do implementations conform to this
requirement in a consistent manner?

 (3) if they are acceptable, should one avoid using designators for
SYNONYM-STREAMs?

 (4) are there informative examples that illustrate the pros and cons
of using stream designators in the context of SYNONYM-STREAMs?
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх