Because BASIC supported GOSUB recursion only, without a parameter stack, I eventually abandoned it in frustration and wrote a compiler for a Pascal style language. The recursive solution is easy, but the question still stands: why are for-loops too weak to express this?
-
Show this thread
-
A Haskell programmer will use some higher-order library functions to build a list comprehension over a variable number of permutations, but that's tricky and just moves the recursion to a library function.
4 replies 1 retweet 40 likesShow this thread -
There's actually a deep answer to this: looping over just mutable loop variables isn't very powerful. A set of n simple nested loops of k iterations each can only explore k^n possibilities, and n must be static. We can't handle n being a variable.
2 replies 1 retweet 43 likesShow this thread -
This is another area where the functional logic language family is more powerful. There, we can loop over multi-valued choices (like little forks whose scope is limited to the enclosing loop) and gather all of their results in sequence through backtracking.
1 reply 1 retweet 37 likesShow this thread -
Here, let "a..b" represent the choice of all values in the range from a to b, and "for(a) do b" loop over all choices in a, producing an array containing the values of b. Then we can write a simple loop like:pic.twitter.com/yVYAUSLSR3
3 replies 2 retweets 31 likesShow this thread -
-
Replying to @ben_a_adams
It has to be inclusive if it's to be non-confusing and to work for any finite ordered values, such as 'A'..'Z'. Thus if used on loops, you'd write for(i=0..count-1).., which is ugly but fortunately uncommon if loops also support for(a:MyArray) iteration without indices.
1 reply 0 retweets 1 like -
Replying to @TimSweeneyEpic
Curious as have had the discussion recently with C#8 index and ranges features, which are exclusive. Inclusive is more understandable when written 'A'..'Z'; however when you use with other operators (.IndexOf to find delimiter) then exclusive flows better https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#indices-and-ranges …pic.twitter.com/tTq6ZCYc1a
2 replies 0 retweets 1 like -
Replying to @ben_a_adams
There is a very frustrated functional logic language trapped in C# wanting to get out! All of the pattern matching features would've fallen out of unification. Null folding operations would have fallen out if boolean-producing operations were instead potentially failing.
2 replies 0 retweets 1 like -
Replying to @TimSweeneyEpic @ben_a_adams
Iterators and loops could've been built on backtracking rather than IEnumerable and could have been expressions producing collections instead of statements, yielding a more powerful version of list comprehension, thus no need for LINQ.
1 reply 0 retweets 0 likes
Transactions could have sanitized multithreaded imperative code, alas that effort was abandoned for lack of pre-existing code that would benefit from it.
-
-
Replying to @TimSweeneyEpic @ben_a_adams
Futures could have been flexible unificands. XAML could have been a far simpler constant-only subset of C#. Complicated by-value/by-reference rules inherited from C++ could have been solved with IORef based mutability with simple semantics. Alas!
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.