Just a short answer to clarify and come closer to a design decision.
In this case I can immediately say that any access to the stream will be an
error. So the guideline is "error as early as possible, but no expanding of
the stream is forbidden until a value is needed.
I would delete 'no' from what you wrote, otherwise I do not know
what it means.
Of course. "no" should go away.
I would write "error on access. but not earler".
That somehow is in contradiction to the general principle "error as
early as possible".
And 'st(-3..0)' does not count as access.
Yes, I agree. But it does not mean, that an implementation cannot find
out that any access to the resulting stream will be an error.
t := st(-4..1)
Same here.
I would still say, there should be an
immediate error for two reasons
A) In a stream to get t(6) the previous entries should have been
computed. (Admittedly a questionable reason.)
Yes. 't(6)' should give error. Computing earlier entries is _very_
fundamental for streams.
B) (-4..1) clearly does not fall into the source domain in the sense of
"streams are considered as functions from {1,2,..,n} of from all
positive integers to the coefficients.
Case B is the actual reason why I would want an immediate error.
You mean 'st(-4..1)' is computed?
No. I mean that to compute the resulting stream, no element of st is
ever evaluated. But from the -4 bound, the implementation can find out,
that the resulting stream will give an error.
Now, of course, it is a design decision whether we say, that if a user
computes st(-4..1) then that should give an immediate error or whether
it is allowed to create such a stream without error, but any access to
it would lead to an error.
I see your point that lazyness overrules everything even to create a
stream that leads to error on any evaluation. Oh, I just wanted to give
this example ...
(1) -> f(): Integer == error "no element"
Function declaration f : () -> Integer has been added to workspace.
Type: Void
(2) -> st: Stream Integer := stream(f)
Compiling function f with type () -> Integer
Error signalled from user code in function f:
no element
Either I do something wrong or the implementation of the "stream"
function is not truely lazy.
If you want st(-4..1) to give no error, then stream(f) should also be OK
and only stream(f).1 should signal an error.
My opinion was/is that st(-4..1) can be figured out immediately to give
a "bad" stream, so signal an error. stream(f) should give no error,
since creation of stream forbids evaluation and the current
implementation is actually wrong.
I can agree with "lazyness overrules early error", but then it should be
consistent in all of the implementation of Stream and is must be clearly
stated in the docstring of Stream or even of LazyStreamAggregate (as
design decision).
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/24483365-924f-8cf9-50c2-3a79b9b641a7%40hemmecke.org.
