8000 Add reiterable built-in · Issue #271 · evhub/coconut · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Add reiterable built-in #271
Closed
Closed
@pchampin

Description

@pchampin

I am not an expert in functional programming. That being said, it seems to me that the notion of "lazy list" in coconut is significantly different from their counterpart in e.g. Haskell.

Consider the following function (and the associated micro test-suite below):

def list_type(xs):
    case xs:
        match [fst,snd]::tail:
            return "at least 2"
        match [fst]::tail:
            return "at least 1"
        match (| |):
            return "empty"

assert list_type((|1,2,3,4,5|)) == "at least 2"
assert list_type((|1,2,3,4|)) == "at least 2"
assert list_type((|1,2,3|)) == "at least 2"
assert list_type((|1,2|)) == "at least 2"
assert list_type((|1|)) == "at least 1"  # this test fails, we get "empty"
assert list_type((| |)) == "empty"

The penultimate test fails, because the first match clause consumes the first item of the iterator. I did test an equivalent function in Haskell, and it works as expected. So there is a mismatch here between Coconut and Haskell in how they use pattern matching. My understanding is that pattern matching is more appropriate for immutable values, and iterators are definitely mutable.

This divergence between Haskell (and, AFAIK, other functional languages) and Coconut, can be considered either a bug or a feature...

If it is considered a feature, then I would suggest to put a warning message in the documentation, and examples of do's and dont's when using case statements for iterators... and possibly replacing the name "lazy list" with something else. It is bound to confuse people with a background in functional programming. And I would argue that it may also confuse Python programmers with no such background, because a list is, in general, something more "stable" than an iterator.

I would lean towards considering this as a bug, though. Lazy lists as immutable values are closer to what other functional languages use, and open space for more optimizations... But I understand that this would be a heavy change in the language...

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0