Namely, important part of lazyness is that deferred
computation may contain error. In particular, deferred computation
may be created first and only later code may decide that result
is is not needed, thus avoiding error.
OK, then we go for "defer error". The lazy principle means that only
"empty?" is allowed to evaluate the stream. Other operations should just
build structures that access stream values only when the user asks for them.
I am only a bit worried about such complete lazyness, because it
basically adds lots of SPADCALLs for the evaluation of a stream.
One could avoid one layer of such a call if one verifies that
explicitlyEmpty? x or lazy? x or uninitialized? x (*)
gives false and thus one could safely access frst(x) and thus build a
structure that is explicit and does not need a lazyEval before the user
can access the first value.
It would, however be nice if that weren't 3 tests but just one like
'isMagig? x'. The (*) above is actually a pointer comparison. No idea
whether one can invent another mechanism with just one test. Perhaps you
tell me that (*) would anyway be inlined and quire fast.
I think that proper semantics for 'elt(s, 1..b)' is "truncate the
stream after element number b".
OK. then the design decision is:
If i=1.. or i=1..e describes the indices of a given stream s and u is a
universal segment of the form a..b by c, then s(u) should be
[s.idx for idx in i | idx in expand(u)]
with the obvious meaning of the condition 'idx in expand(u)'.
In contrast to List (where '[1,2,3](2..5)' should give an error), for
Stream we could favour an empty stream instead of an "index out of
range" error.
In fact, we could have the same semantics for lists, but it would
somehow feel unnatural for me. I would actually rather expect an error
from [1,2,3](4..4) (as being equivalent to the list consiting of the
element [1,2,3].4). But OK, that's open for discussion.
elt(s, a..b) must give an error of a or b are bigger than maxIndex(x) (maybe
a delayed error as discussed above).
AFAICS error should come from accessing empty stream.
OK.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/998ec4da-368e-d99f-0d35-f5ae5638c2cd%40hemmecke.org.
