New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature wish: tail recursion modulo cons #8010
Comments
Comment author: administrator Brian,
I have mixed feelings about this. Yes, lists are often used and a
It is. My reaction in this situation is to try to come up with better
I'm not opposed to recoding some of the List functions with setcdr, I'd rather not expose setcdr to the programmers, though. It would
Agreed. But I'm very reluctant to complicate the type system by In other terms, there are ideas that make nice research papers, and Non-type-based optimizations of tail recursion modulo constructors Thanks for your feedback,
|
Comment author: @mshinwell I think this issue is superfluous. Frederic Bour has a TRMC implementation that may be discussed further. |
Original bug ID: 1538
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-06T20:43:06Z)
Resolution: not a bug
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Brian Rogoff
Version:
OS:
Submission from: 12-234-80-157.client.attbi.com (12.234.80.157)
Hi,
As has been discussed on the mailing list, I wish that OCaml would perform
the
tail recursion optimization on a larger class of functions than it does
currently.
One example is List.map. Several times I've had customers run programs on some
fairly large data and had the stack blown. One could argue that one shouldn't
use
lists for such programs, but that's silly. Lists are a fundamental data
structure in
FPLs, like floating point arrays in Fortran, so we really should maximize their
power.
performace by doing everything backwards and reversing the result. That's the
usual
approach I take, but now that I know that there is a better way, it seems
wasteful.
coded using Obj functions, and a similar approach will work for the same problem
with
other data structures, like trees. I've added a module of List functions recoded
using this approach to my library. However, I dislike this for the same reason I
dislike the previous approach; it appears that there are a few solutions for ML
style languages. Caml should have one.
lists
and optimize it, since that's where I get bit currently, but a type system
extension
like Minamide's or the Walker/Morrisett alias types would allow this for
arbitrary data structures. Yes, it's more than just doing tail call
optimization, it requires a type system extension, and the functions would need
to be coded differently. But you guys are language researchers, so it would
probably be a lot of fun, and worth a few
papers. Just adding set-cdr! or special casing List.map and friends isn't really
research ;-)
-- Brian
The text was updated successfully, but these errors were encountered: