IIUC the official idiom always was:
p4 := entries(complete(partitions(4)))
OK. Grummel.
Justification is that othewise one may trigger infinite loop
by accident. 'complete' is supposed to be used only to
force computation off all entries, so no risc of accident.
I must admit that I do not see how it makes more sense to let
entries: % -> List S
return an infinite stream error and require to user to explicitly call
"complete" when the user knows that the stream is finite and "entries"
is supposed to return a list.
The only infinite case would be that the stream st contains a cycle, but
in this case complete(st) runs into an infinite loop. So we can actually
expect either that "entries" returns a list or runs indefinitely in case
the stream is not finite.
Note that the result of "entries" is not lazy any more. So I bet an
ordinary user expects that "entries" calls "complete" implicitly.
with unsafe one viewed as exceptional and essentially
confined to a ghetto.
I agree that restricting unsafe operations to a few functions makes
sense, but in this special case... I would rather declare "entries" to
be a unsafe function.
Introducing "computedEntries: % -> List(S)" makes probably no sense,
since nobody asked for it.
I can live with "(s = copy(s))@Boolean" returning false in general, but
letting "entries" abort the computation if it is not yet verified that
the stream is finite is another case.
So I propose that we include "complete" into the definition of
"entries". Or at least add a statement to the error message that one
should apply "complete" if one knows that the stream is finite.
The problem would not have appeared if partitions(n) would return a List
instead of a Stream, but admittedly for big n one might not actually
want all partitions at once so a lazy aggregate makes sense.
Maybe all this calls for an explicit type FiniteStream (or LazyList)
which is lazy, but otherwise behaves like List.
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/22bfeff8-64be-be9b-026e-bd9e66ebfe92%40hemmecke.de.