= 27d567bc2d48d9f40e9ccc20ea370b15)
JGWeissman comments on Course recommendations for Friendliness researchers - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (113)
A functional language could compile to code that uses references to continuations (functions to call, with parameters) instead of the physical stack. See continuation passing style. (The language wouldn't need to use continuation passing style itself, the conversion would straightforward for the compiler to do.)
That, to me, falls under "Trying to figure out ways around the constraints imposed by the language."
I suspect it would have made for even messier code, as well, provided it would have even worked for that particular problem. I was parsing a deliberately and ingeniously obfuscated document, and I was updating particular pieces of information based on information obtained in recursive references which, needless to say, were obfuscated, including false flag references which would get me incorrect information if followed; the falsity couldn't be determined locally, either, and required complex conditional comparisons to information contained in parent references. Some of the references were cyclical, to boot.
Functional languages do not have inherent stack limits. A stack limit is imposed by a particular implementation of the language, and what I described is how a different implementation of the language could have a much larger stack limit, (constrained by total memory rather than memory initially allocated to the physical stack), with no difference in the source code because the compiler can make the transformation to continuation passing style for you.
The point is that this problem you had with XSLT does not generalize to all possible functional languages the way you think it does.
Hm. Granted.
In fairness, I think it does generalize to most implementations.