Programming Languages – Is Using ‘yield’ for Generators a Good Idea?

language-agnosticlanguage-designlanguage-featuresprogramming-languages

PHP, C#, Python and likely a few other languages have a yield keyword that is used to create generator functions.

In PHP: http://php.net/manual/en/language.generators.syntax.php

In Python: https://www.pythoncentral.io/python-generators-and-yield-keyword/

In C#: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/yield

I am concerned that as a language feature/facility, yield breaks some conventions. One of them is what I'd refer to is "certainty". It is a method that returns a different result every time you call it.
With a regular non-generator function you can call it and if it is given the same input, it will return the same output. With yield, it returns different output, based on its internal state. Thus if you randomly call the generating function, not knowing its previous state, you cannot expect it to return a certain result.

How does a function like this fit into the language paradigm? Does it actually break any conventions? Is it a good idea to have and use this feature? (to give an example of what's good and what's bad, goto was once a feature of many languages and still is, but it is considered harmful and as such was eradicated from some languages, such as Java). Do programming language compilers/interpreters have to break out of any conventions to implement such a feature, for example, does a language have to implement multi-threading for this feature to work, or can it be done without threading technology?

Best Answer

Caveats first - C# is the language I know best, and while it has a yield that seems to be very similar to other languages' yield, there may be subtle differences I am unaware of.

I am concerned that as a language feature/facility, yield breaks some conventions. One of them is what I'd refer to is "certainty". It is a method that returns a different result every time you call it.

Poppycock. Do you really expect Random.Next or Console.ReadLine to return the same result every time you call them? How about Rest calls? Authentication? Get Item off a collection? There are all sorts of (good, useful) functions that are impure.

How does a function like this fit into the language paradigm? Does it actually break any conventions?

Yes, yield plays really badly with try/catch/finally, and is disallowed (https://blogs.msdn.microsoft.com/ericlippert/2009/07/16/iterator-blocks-part-three-why-no-yield-in-finally/ for more info).

Is it a good idea to have and use this feature?

It's certainly a good idea to have this feature. Things like C#'s LINQ is really nice - lazily evaluating collections provides a big performance benefit, and yield allows that sort of thing to be done in a fraction of the code with a fraction of the bugs that a hand-rolled iterator would.

That said, there's not a ton of uses for yield outside of LINQ style collection processing. I've used it for validation processing, schedule generation, randomization, and a few other things, but I expect that most developers have never used it (or misused it).

Do programming language compilers/interpreters have to break out of any conventions to implement such a feature, for example, does a language have to implement multi-threading for this feature to work, or can it be done without threading technology?

Not exactly. The compiler generates a state machine iterator that keeps track of where it stopped so that it can start there again the next time it is called. The process for code generation does something akin to Continuation Passing Style, where the code after the yield is pulled into its own block (and if it has any yields, another sub-block, and so on). That's a well known approach used more often off in Functional Programming and also shows up in C#'s async/await compilation.

No threading is needed, but it does require a different approach to code generation in most compilers, and does have some conflict with other language features.

All in all though, yield is a relatively low impact feature that really helps with a specific subset of problems.

Related Solutions

Meant by “native support for a feature” in a programming language

It means that to support a given feature, the developer doesn't need to use a component which is not embedded in the language itself, like an extension or a third party product.

For example, PHP has no native support for unicode, because every function which deals with strings in PHP itself doesn't support unicode. For example, in order to get a substring, you can't use substr, but need to use mb_substr, which requires to use the Multibyte String extension.

To have a native support of a given feature, it is not enough to just incorporate an extension in the source code trunk. Instead, PHP would have native support for unicode if unicode would be the default encoding, like in C# or Java.

Programming Languages – Dealing with Unknown Parameter Names in Functions

I agree that the way functions are often used can be a confusing part of writing code, and especially reading code.

The answer to this problem partly depends on the language. As you mentioned, C# has named parameters. Objective-C's solution to this problem involves more descriptive method names. For example, stringByReplacingOccurrencesOfString:withString: is a method with clear parameters.

In Groovy, some functions take maps, allowing for a syntax like the following:

restClient.post(path: 'path/to/somewhere',
            body: requestBody,
            requestContentType: 'application/json')

In general, you can solve this issue by limiting the number of parameters you pass to a function. I think 2-3 is a good limit. If it appears that a function needs more parameters, it causes me to re-think the design. But, this can be harder to answer generally. Sometimes you are trying to do too much in a function. Sometimes it makes sense to consider a class for storing your parameters. Also, in practice, I often find that functions which take large numbers of parameters normally have many of them as optional.

Even in a language like Objective-C it makes sense to limit the number of parameters. One reason is that many parameters are optional. For an example, see rangeOfString: and its variations in NSString.

A pattern I often use in Java is to use a fluent-style class as a parameter. For example:

something.draw(new Box().withHeight(5).withWidth(20))

This uses a class as a parameter, and with a fluent-style class, makes for easily readable code.

The above Java snippet also helps where the ordering of parameters may not be so obvious. We normally assume with coordinates that X comes before Y. And I normally see height before width as a convention, but that is still not very clear (something.draw(5, 20)).

I've also seen some functions like drawWithHeightAndWidth(5, 20) but even these can't take too many parameters, or you'd start to lose readability.

Best Answer

Related Solutions

Meant by “native support for a feature” in a programming language

Programming Languages – Dealing with Unknown Parameter Names in Functions

Related Topic