What's a coroutine in a language agnostic sense?
In particular, I'm confused about whether there's necessarily a difference between a
factory for stamping-out-but-not-transferring-control-to execution contexts
the execution contexts themselves
If you insist on having such a distinction, I think you get a Lua-like system. Here's an example adapted from here.
function coroutine_body()
print("hi")
end
execution_context = coroutine.create(coroutine_body)
The example on Wikipedia, though, appears not to have such a distinction.
I'm wondering what the right way is to think about coroutines if such a distinction does not exist.
Here is the article defining a coroutine on Wikipedia.
Here's an example coroutine in pseudocode, following Wikipedia's example. It looks straightforward, and shows a nice example of cooperative multitasking by passing control around.
var q := new queue
coroutine produce
loop
while q is not full
create some new items
add the items to q
yield to consume
coroutine consume
loop
while q is not empty
remove some items from q
use the items
yield to produce
call produce
I'm trying to understand the details of this fake programming language and am trying to work through it step by step to understand what happens when.
Let's assume that we start out in a coroutine called main. I'm picking main arbitrarily as the coroutine that we're in by default or, equivalently, the coroutine that has control at the start of the program.
We create a global variable q.
We then define a new coroutine produce. The coroutine definition creates a new execution context called produce that's a peer with main. main still has control; we haven't given it up.
The next coroutine statement consume creates a new execution context called consume that is a peer with main and produce. Again main still has control.
Now we call produce.
This part I don't understand. I don't get why we don't yield to produce instead.
It also seems to me like produce has a different meaning as a top-level definition than it does as a free variable within the body of consume.
Similarly, I don't understand why we aren't forced to write the following, which has a very explicit distinction between execution contexts (here called coroutine_instances) and coroutines which produce new suspended execution contexts and return them as a value.
var q queue := new queue
var p coroutine_instance := null
var c coroutine_instance := null
coroutine produce
loop
while q is not full
create some new items
add the items to q
yield to c
coroutine consume
loop
while q is not empty
remove some items from q
use the items
yield to p
p = produce()
c = consume()
yield to p
Related
What is a simple technique to perform some action just once, no matter how many times the function is executed? Do any programming languages have specific ways built-in to handle this somewhat common problem?
Example: initialize() shall set global_variable to true on ONLY its first execution.
A c++ example (looking for alternatives to this out of curiosity - not necessity):
init.h:
int global_variable;
void initialize(void);
init.c:
static bool already_initialized = false;
void initialize(void)
{
if (!already_initialized)
{
already_initialized = true;
global_variable = true;
}
}
Apart from the global variable technique that's available in any language there are several other ways to do this.
In languages that have static variables using a static variable instead of global is preferable in order to prevent variable name collisions in the global scope.
In some languages you can redefine/redeclare functions at runtime so you can do something like this:
function initialize (void) {
// do some stuff...
function initialize(void) {}; // redefine function here to do nothing
}
In some languages you can't quite redeclare functions within functions due to scope issues (inner functions) but you can still reassign other functions to an existing function. So you can do something like this:
function initialize (void) {
// do some stuff ...
initialize = function (void) {}; // assign no-op anonymous function
// to this function
}
Some languages (especially declarative languages) actually have a "latch" functionality built in that executes just once. Sometimes there is even a reset functionality. So you can actually do something like this:
function do_once initialize (void) {
// do some stuff
}
If the language allows it you can reset the do_once directive if you really want to re-execute the function:
reset initialize;
initialize();
Note: The C-like syntax above are obviously pseudocode and don't represent any real language but the features described do exist in real languages. Also, programmers rarely encounter declarative languages apart from HTML, XML and CSS but Turing complete declarative languages do exist and are typically used for hardware design and the "do_once" feature typically compiles down to a D flip-flop or latch.
Eiffel has a built-in notion of once routines. A once routine is executed only the first time it is called, on the next call it is not executed. If the routine is a function, i.e. returns a result, the result of the first execution is returned for all subsequent calls. If the first call terminates with an exception, the same exception is raised for all subsequent calls.
The declaration of the once function foo looks like
foo: RETURN_TYPE
once
... -- Some code to initialize Result.
end
In a multithreaded environment it might be desirable to distinguish objects used by different threads. This is accomplished by adding the key "THREAD" to the declaration (it is actually the default):
foo: RETURN_TYPE
once ("THREAD")
...
end
If the same object has to be shared by all the threads, the key "PROCESS" is used instead:
foo: RETURN_TYPE
once ("PROCESS")
...
end
The same syntax though without return type is used for procedures.
Process-wide once routines are guaranteed to be executed just once for the whole process. Because race conditions are possible, Eiffel run-time makes sure at most one thread may trigger evaluation of the given once routine at a time. Other threads become suspended until the primary execution completes so that they can use the single result or be sure the action is performed only once.
In other respects once routines are no different from the regular routines in a sense that they follow the same rules of object-oriented programming like inheritance and redeclaration (overriding). Because this is a normal routine it can call other routines, directly or indirectly involving itself. When such a recursive call occurs, the once routine is not executed again, but the last known value of the result is returned instead.
yes, some languages (scala) does support it (using lazy) but usually this functionality is provided by frameworks because there are some trade offs. sometimes you need thread level, blocking synchronization. sometimes spin-offs is enough. sometimes you don't need synchronization because simple single-threaded cache is enough. sometimes you need to remember many calculated values and you are willing to forget last recently used ones. and so on. probably that's why languages generally don't support that pattern - that's frameworks' job
I will use C# syntax since I am familiar with it, but it is not really language-specific.
Let's say we want to provide an API to go over a Tree and do something with each Node.
Solution 1: void Visit(Tree tree, Action<Node> action)
It takes a tree, and calls action on each node in the tree.
Solution 2: IEnumerable<Node> ToEnumerable(Tree tree)
It converts tree to a flat lazy sequence so we can go over and call action on each node.
Now, let's see how we can convert one API to another.
It is pretty trivial to provide Visit on top of ToEnumerable:
void Visit(Tree tree, Action<Node> action) {
ToEnumerable(tree).ForEach(action);
}
However, is there a concept/feature in any language that will allow to provide ToEnumerable on top of Visit (as lazy sequence, so list is not created in advance)?
Not sure if I understand you correctly, but in Python, you can create iterable interface on any object.
So you would just add special method __iter__ (which will yield nodes while traversing the tree).
The visit procedure is then just about iterating through Tree object and calling action on each node.
If you are writing the code that will visit each node (as with a tree), it's possible to have an iterator call iterators for each branch, and perform a yield return on leaf nodes. This approach will work, and is very simple, but has the serious disadvantage that it's very easy to end up with code that will be very readable but execute very slowly. Some other questions and answers on this site will offer insight as to how to traverse trees efficiently within an iterator.
If the "tree" was just an example, and what you really have is a class which exposes a routine to call some delegate upon each node (similar to List.ForEach()), but does not expose an IEnumerable, you may be able to use the former to produce a List, which you could then iterate. Use something like var myList = new List<someThing>(); myCollection.ForEach( (x) => myList.Add(x) ); and then you may be able to enumerate myList.
If even that isn't sufficient, because the objects that were added to the list may not be valid by the time enumeration is complete, it may in rare cases be possible to use multiple threading to accomplish what's needed. For example, if you have two sorted collections whose ForEach method prepares each items for use, does the specified action, and then cleans up each item before proceeding to the next, and if you need to interleave the actions on items from two independent collections, one might be able to iterate the collections on separate threads, and use synchronization primitives so each thread will wait as necessary for the other.
Note that collections which only expose themselves via ForEach method are apt to restrict access during the execution of such a ForEach (if such restriction weren't necessary, they would probably implement IEnumerable). It may be possible for the "item action" called by one ForEach to perform another ForEach on the same collection on the same thread, since the latter ForEach would have to complete before the former one could resume. While one ForEach is running, however, an attempt to call a ForEach on a second thread would likely either malfunction or wait for the first operation to complete. If the first ForEach was waiting for some action by the second, deadlock would result. Because of this, scenarios where multi-threading will work better than simply building a List are rare. Nonetheless, there are a few cases where it may be helpful (e.g. the above-mentioned "zipper" operation on independent collections).
I think now I understand the idea. The concept that I need here is called first-class continuations or, specifically, call/cc. The confusing thing about it for me is that C# already provides a limited implementation of this concept in yield return, but it is not applicable to my scenario.
So if C# provided full implementation, the solution would look like:
IEnumerable<Node> ToEnumerable(Tree tree) {
tree.Visit(node => magic yield return node);
}
where magic yield return instead of returning sequence from node => ... lambda returns next element from ToEnumerable.
However, this answer is still not complete as I do not see the exact correlation between yield return and call/cc. I will update the answer when I understand this.
Just seen an interesting possibility to initialize code blocks in Scala for high order functions such as foreach or map:
(1 to 3) map {
val t = 5
i => i * 5
}
(1 to 3) foreach {
val line = Console.readLine
i => println(line)
}
Is this some documented feature or should I avoid such constructs? I could imagine, the "initialization" block comes into the constructor and the closure itself becomes an apply() method?
Thanks Pat for the original Question (http://extrabright.com/blog/2010/07/10/scala-question-regarding-readline)
While the features used are not uncommon, I'll admit is is a fairly odd combination of features. The basic trick is that any block in Scala is an expression, with type the same as the last expression in the block. If that last expression is a function, this means that the block has functional type, and thus can be used as an argument to "map" or "foreach" . What happens in these cases is that when "map" or "foreach" is called, the block is evaluated. The block evaluates to a function ( i=> i*5 in the first case ), and that function is then mapped over the range.
One possible use of this construct is for the block to define mutable variables, and the resulting function mutate the variables each time it is called. The variables will be initialized once, closed over by the function, and their values updated every time the function is called.
For example, here's a somewhat surprising way of calculating the first 6 factorial numbers
(1 to 6) map {
var total = 1
i => {total *= i;total}
}
(BTW, sorry for using factorial as an example. It was either that or fibonacci. Functional
Progamming Guild rules. You gotta problem with that, take it up with the boys down at the hall.)
A less imperative reason to have a block return a function is to define helper functions earlier in the block. For instance, if your second example were instead
(1 to 3) foreach {
def line = Console.readLine
i => println(line)
}
The result would be that three lines were read and echoed once each, while your example had the line read once and echoed three times.
First, the comment of the original blog "Scala Question Regarding readLine" post mention
The “line” is a value and cannot be executed, it is assigned only once from the result of the “Console.readLine” method execution.
It is used less than three times in your closure.
But if you define it as a method, it will be executed three times:
(1 to 3) foreach {
def line = Console.readLine
i => println(line)
}
The blog Scala for Java Refugees Part 6: Getting Over Java has an interesting section on Higher Order function, including:
Scala provides still more flexibility in the syntax for these higher-order function things.
In the iterate invocation, we’re creating an entire anonymous method just to make another call to the println(String) method.
Considering println(String) is itself a method which takes a String and returns Unit, one would think we could compress this down a bit. As it turns out, we can:
iterate(a, println)
By omitting the parentheses and just specifying the method name, we’re telling the Scala compiler that we want to use println as a functional value, passing it to the iterate method.
Thus instead of creating a new method just to handle a single set of calls, we pass in an old method which already does what we want.
This is a pattern commonly seen in C and C++. In fact, the syntax for passing a function as a functional value is precisely the same. Seems that some things never change…
My programming language has no arrays, no lists, no pointers, no eval and no variable variables. All it has:
Ordinary variables like you know them from most programming languages: They all have an exact name and a value.
One stack. Functions provided are: push (add element to top), pop (remove element from top, get value) and empty (check if stack is empty)
My language is turing-complete. (Basic arithmetics, conditional jumps, etc implemented) That means, it must be possible to implement some sort of list or array, right?
But I have no idea how...
What I want to achieve: Create a function which can retrieve and/or change an element x of the stack.
I could easily add this function in the implementation of my language, in the interpreter, but I want to do it in my programming language.
"Solution" one (Accessing an element x, counting from the stack top)
Create a loop. Pop off the element from the stack top x times. The last element popped of is element number x. I end up with a destroyed stack.
Solution two:
Do the same as above, but store all popped off values in a second stack. Then you could move all elements back after you are done. But you know what? I don't have a second stack!
Sounds like a homework question, as it flexing random bits of Computer Science...
I think you would want to use recursion to do this. Say I have something like this..
Queue globalQueue = new Queue();
Then I could have code that got element X like this
public Object findElement(stepsToTake s) {
if (queue.empty()) {
throw new EmptyQueueYouFailException();
}
Object o = queue.pop();
if (s == 0) {
queue.push(o);
return o;
}
Object actualResult = findElement( s - 1 );
//restore this element to the stack
queue.push(o);
//return actual result
return actualResult;
}
So more likely than not I made some bug... have not thought through it super well. Especially worried that I will reorder the stack because of the order of my calls..
Hopefully this can get you thinking along the right lines to get a solution?
Do you have procedure calls and recursion? Then you do have a second stack, the call stack. If not, are you sure it's Turing complete, and not just a PDA?
If you have only one stack, this is equivalent to a pushdown automaton, which can recognize context-free languages, and is not Turing-complete. Your proof of Turing completeness should inform how you can implement freeform memory access.
In general, to prove Turing-completeness, you must be able to show how your language can move left to right over a tape (or indirectly simulate this process), which corresponds roughly to a single higher-level array.
I dont even know what caused it in my application. What is it? I created a new instance of a class (the class was in another file), but at the first time I call a method it throws a StackOverFlow exception.
The only thing that I think would logically throw a stackoverflow exception would be if someone downvoted Jon Skeet.
But seriously now, what is it? I got around it by creating another class in the same file as the first class and using that to call the methods for me.
As a general rule, a stack overflow exception is caused by a recursive algorithm where the depth of recursion has exceeded the (typically) fixed stack limit. This is usually a result of a bug in the algorithm, but it may also be caused by the data structure you are applying the algorithm to being too "deep".
Here's a trivial example of a buggy recursion (in no particular PL).
function int length(list l) {
if (empty(l)) {
return 0;
} else {
return 1 + length(l); // should be 'return 1 + length(tail(l));
}
}
Calling length for any non-empty list will give a stack overflow in a typical programming language. But even if you correct the bug, calling the method for a long list is likely to cause a stack overflow.
(The exception is when you use a language ... or more strictly a compiler ... that supports tail recursion optimization.)
A stackoverflow exception is when you exceed the allocated stack size, this generally occurs from recursively calling methods and never leaving, it can also be cause by various obscure method chaining. The issue is you probably have something to the extent of the following in the object.
void MyMethod()
{
MyMethod();
}
The calls will eat up and never free the stack space used because the calls never end execution and the entry point must remain.
P.S. SO was named for the particular exception in question (this is fundamental and not limited to .NET), it's just a clever name for a developer site.
StackOverFlows Exceptions are exactly what they sound like, the stack overflows. Usually this is because you have a circular dependency in your methods. For instance method A calls B and B calls A. Or it could be a recursive method without a base case.
Without seeing the code it is impossible to tell why this happened but a StackOverflowException is thrown when a thread overflows its call stack. This most often occurs when a method calls itself recursively without any conditional break thus creating infinite recursion. Since each recursion creates a new stack frame an infinite recursion would theoretically create an infinite number of stack frames, I am sure you can now see why the term "stack overflow" is apt.
The Stack is where the computer stores a list of the functions that are currently being called, and the variables and parameters used. So if function Main calls function A, and then function A calls function B, and they use variables c, d and e, the stack will contain all of that information. However, the stack is only so big. So if function B then calls function C, which calls function D... etc, ending up with hundreds of nested functions, eventually, the stack will "overflow" - there isn't enough space to store another function call.
As other people have noted, this usually happens with a recursive function (where function B calls function B, which then calls function B...) - eventually, the stack will overflow. You will need to find where that recursive function is being called, and why it isn't breaking out of the recursive loop when it's supposed to.
Of course, the problem may not be that it's a buggy recursive algorithm - it may just be that the number of function calls exceeds the size of the stack. So if your algorithm has the potential to call a recursive function a few hundred times, it may be that.
This is usually caused by a recursive call to a function where that recursive call never terminates. You may get this in several ways. One way could be a recursive algorithm without a base case, another common one is creating objects A and B that create one of each other in the their constructors, etc.
i recommend you step through the debugger and find out :)
I recently ported an old VB6 application to VB.NET which used a monstrous recursive function to sort an equally large amount of data. The algorithm was fine but execution consistently caused a stack overflow error. After much fiddling, I realized that VB was doing to much magic behind the code: easy type casting comes with a price. So the recursive function was relying way too much on late binding instead of using type variables and this resulted in HUGE amount of casting, parsing, etc. overhead (a single line of code could call from 2 to 10 functions...) which, obviously, made the stack overflow.
TL;DR: Use DirectCast() and static binding (typed variables) to prevent VB from flooding the stack at runtime in a recursive function.
I had this problem occur, I noticed that I mis-typed lstEncounter. As I learned in my C++ class, the problem is the recursive algorithm of basically calling itself with the same parameters. My example where I got the error:
Property Encounter(ByVal N As Integer)
Get
If N < lstEncounters.Count Then
Return Encounter(N)
Else
Return Nothing
End If
End Get
Set(value)
lstEncounters(N) = value
End Set
End Property
I was having a Stackoverflow error.
I was using a routine that added 1 to a counter then re called the same routine.
About every 2500 to 3000 loops I got the stackoverflow error.
I have added a DO...Loop that calls the routine, I use VB Express:
BEFORE:
Public Sub mainloop()
Dim cntr as integer
If cntr >= 5000 ( I just picked a number at random)
me.close ( I close the program)
... (This is where I would manipulate the cntr for diff
results)
cntr = cntr + 1 ( increment the cntr)
mainloop() (re call my loop)
End IF
End Sub
(as I said before, after about 2500-3000 I would get the Stackoverflow error)
AFTER: (Place this to execute first)
Dim LoopCntr as integer
Do While LoopCntr <= 40000 (this my number.. Use your own number)
If LoopCntr > 40000 Then
Exit Do
End If
mainloop() (The mainloop() has not been changed just the method of calling it)
LoopCntr = LoopCntr + 1
Loop
me.close (When LoopCntr reaches max it closes the program)
(After adding the Do..Loop my program ran 40000 time without "Stackoverflow")