@Zgarb That's really nice, I like how well it behaves with infinite lists of lists

I like infinite numbers too, I was thinking about implementing them but I couldn't decide what to do for edge cases like +inf-inf, or 0*inf... Did you just choose arbitrary results or do you have some insights on that?

By the way, since division by zero and indexing into empty lists are no longer errors (and we may want to eventually replace all sources of error with some meaningful values), we should probably implement undefined, mostly for those challenges wich require exiting with an error, or even as an alternate way of terminating computations (even if it's harder to use like this with Haskell compared to other languages)

I also think there is a bug with your maximum/minimum, you should swap their default values because right now maximum always returns inf and minimum -inf

Oh, and most importantly, welcome back! :D

Didn't see what you actually meant, I agree.

I think func_maxl = foldr max func_minval would be correct

Yes, me too

Or maybe it could even be possible to make it work smartly on big lists by returning early if maxval is found in the list... but I guess that would be a lot of work for few gains

Bug?

@H.PWiz I think readsPrec for TNum might need an otherwise clause returning an empty list. I tried it on my pc and it solves this specific bug, but since I don't really know how/when readsPrec is used I'll wait for Zgarb's opinion to avoid breaking other things

@Leo @H.PWiz Yeah, it seems I created a couple of bugs, sorry. :/ I'll fix them later today.

@Leo The edge cases I chose to implement pretty arbitrarily.

@Leo Well, /0 0 does result in NaN already, since / uses Double division internally. We could change that to "undefined" and implement our own rules for it, although I'm not sure how NaN actually works. Doubles also have a form of infinity, but I rolled a custom one since it doesn't play well with comparison to integers.

There, bugs hopefully fixed.