Suggestions
  1. Suggestions
  2. SUGGEST-18

Variable arguments extractors are impossible to use efficiently with a non-standard library

    Details

    • Type: Suggestion Suggestion
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:

      Description

      unapplySeq[T] requires an Option[Seq[T]] output, but Seq is a huge trait with innumerable methods and sub-traits that have nothing to do with implementing the pattern matching. Thus a non-standard library, which uses a different collections library, is unable to return its collections without creating a copy that is a Seq. This is because for a non-standard library collection to extend a Seq requires implementing or including too much functionality from Scala's standard library.

      The pattern matching feature has been conflated with the standard Scala library. If Scala wants to be truly open then it should allow for other libraries to work efficiently with compiler features, such as pattern matching. The variable argument extractor doesn't need most of the methods from Seq, it probably only needs a simple iterator. Given Scala claims to be scalable and compositional, I hope the minimum necessary trait for doing variable argument extraction can be defined and supported with a new unapplyXXX extractor.

      The same principle could be applied to the use of the Option type for extractors. It would be a better design for the pattern matching compiler feature to not be entangled with the Option type. Instead, an alternative unapplyYYY extractor could return the value or null. I don't like null, but it is a lot less entangled with the standard library.

      The point here is that the compiler functionality should not be entangled with the standard library in any way.

      P.S. I am working on such a non-standard category theory collections library, that is much less complex than Scalaz, because I use novel subtyping paradigm and higher-kinds. I am also working on a language that compiles to Scala and interopts with Scala. I understand Scala was created to be toolset for experimentation in languages and thus I also assume libraries, so I am hoping I can encourage the removal of unnecessary conflation of library and compiler.

        Activity

        Hide
        Simon Ochsenreither added a comment -

        Sorry, but please take this to the appropriate mailing list.

        This is maybe an enhancement request if it had some actual details or some patch, but not a bug especially no major one, IMHO.

        Show
        Simon Ochsenreither added a comment - Sorry, but please take this to the appropriate mailing list. This is maybe an enhancement request if it had some actual details or some patch, but not a bug especially no major one, IMHO.
        Hide
        Paul Phillips added a comment -

        It's a reasonable ambition (at least up to a point, maybe not as much as you want) so I put it in the suggestions database.

        Show
        Paul Phillips added a comment - It's a reasonable ambition (at least up to a point, maybe not as much as you want) so I put it in the suggestions database.
        Hide
        Shelby Moore III added a comment -

        Thank you for moving it to the suggestions database. I wasn't sure where to classify it.

        Sorry for not raising it on the mailing list, but I don't do well in politics.

        I think there are sufficient details in my description. If there is any need for some example code at some point, please feel free to send me an email. I am more than happy to help, and at some point perhaps I can fund someone to work on this issue.

        I suppose I most wanted to ping the Scala compiler developers on the design principle of keeping the compiler features orthogonal to the libraries. Actually that helps them too, because at some point, they may need that flexibility.

        Thanks again.

        Show
        Shelby Moore III added a comment - Thank you for moving it to the suggestions database. I wasn't sure where to classify it. Sorry for not raising it on the mailing list, but I don't do well in politics. I think there are sufficient details in my description. If there is any need for some example code at some point, please feel free to send me an email. I am more than happy to help, and at some point perhaps I can fund someone to work on this issue. I suppose I most wanted to ping the Scala compiler developers on the design principle of keeping the compiler features orthogonal to the libraries. Actually that helps them too, because at some point, they may need that flexibility. Thanks again.
        Hide
        Shelby Moore III added a comment -

        I have a potentially more elegant idea of how to implement this suggestion.

        The specification for unapplySeq, can be changed to Option[...,

        {...iteration method(s) needed...}

        ], i.e. a structural type. If I understand correctly how structural types work, this will be compatible with all the existing unapplySeq (which return an Option[...,Seq]).

        As for my Option versus null point, I agree that may be conceptual overkill. The real cost here is the need to copy from another collections library to a Seq, when it would be preferable for that collections library to simply provide the necessary methods needs (but not inherit from an entire Seq).

        Show
        Shelby Moore III added a comment - I have a potentially more elegant idea of how to implement this suggestion. The specification for unapplySeq, can be changed to Option[..., {...iteration method(s) needed...} ], i.e. a structural type. If I understand correctly how structural types work, this will be compatible with all the existing unapplySeq (which return an Option [...,Seq] ). As for my Option versus null point, I agree that may be conceptual overkill. The real cost here is the need to copy from another collections library to a Seq, when it would be preferable for that collections library to simply provide the necessary methods needs (but not inherit from an entire Seq).
        Hide
        Adriaan Moors added a comment -

        I completely agree. In fact, this is the direction I'm taking the virtualized pattern matcher in. I plan on writing an article about it soon, but in the meantime you can check it out by passing -Yvirtpatmat to a nightly build of scalac. Use -Xprint:typer to see the desugaring in action, or check out the source code at https://github.com/adriaanm/scala-dev/blob/topic/virtpatmat/src/compiler/scala/tools/nsc/typechecker/PatMatVirtualiser.scala

        The idea is that a pattern match can be desugared much like a for-comprehension, except that a zero-plus monad is required. The virtual pattern matcher currently require nominal types for the monad, but the idea is to move towards structural types for the spec and the implementation, so that you can get pretty cheap extractors. For example you could use no-overhead marker objects instead of None or null (suppose your extractor is scrutinizing a Type, you would have a singleton object NoType that has def isEmpty = true to indicate it corresponds to None).

        Show
        Adriaan Moors added a comment - I completely agree. In fact, this is the direction I'm taking the virtualized pattern matcher in. I plan on writing an article about it soon, but in the meantime you can check it out by passing -Yvirtpatmat to a nightly build of scalac. Use -Xprint:typer to see the desugaring in action, or check out the source code at https://github.com/adriaanm/scala-dev/blob/topic/virtpatmat/src/compiler/scala/tools/nsc/typechecker/PatMatVirtualiser.scala The idea is that a pattern match can be desugared much like a for-comprehension, except that a zero-plus monad is required. The virtual pattern matcher currently require nominal types for the monad, but the idea is to move towards structural types for the spec and the implementation, so that you can get pretty cheap extractors. For example you could use no-overhead marker objects instead of None or null (suppose your extractor is scrutinizing a Type, you would have a singleton object NoType that has def isEmpty = true to indicate it corresponds to None).
        Hide
        Shelby Moore III added a comment -

        Attempting to bump up the priority of this suggestion. Don't know what would be involved if I were to try to get involved with implementing it?

        With Ceylon 1.0 shooting for release this year (first alpha released already), Scala might benefit from more experimentation with creating easy-to-use libraries that will be competitive and best matched to the mainstream.

        I am hopeful I can create a library more user friendly than Scalaz (and with documentation!), and more category theory based than the current builders approach (which apparently is experiencing obscure corner cases, as I heard in the Paul Philips interview). I have some initial experimentation to give me a (weak) basis for that claim.

        This conflation of pattern matching (one of Scala's brilliant features) and the standard library, is a potential point of significant competitive weakness, as Gavin King is a library master and afaics (in the Ceylonlanguage design FAQ) is already demonstrating his pragmatism for user friendly design choices. I don't know how long it will take them to challenge Scala, but don't dismiss the exponential speed of a ramping community of huge pool of excited Java developers (against a dozen or so hard-core Typesafe developers).

        Exhibits:

        http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html (see my Modularity, Concurrency, Complexity comments)
        http://blog.joda.org/2011/11/scala-ejb-2-feedback.html
        http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist
        http://grahamhackingscala.blogspot.com/2011/12/will-typesafe-address-scala-criticisms.html

        Show
        Shelby Moore III added a comment - Attempting to bump up the priority of this suggestion. Don't know what would be involved if I were to try to get involved with implementing it? With Ceylon 1.0 shooting for release this year (first alpha released already), Scala might benefit from more experimentation with creating easy-to-use libraries that will be competitive and best matched to the mainstream. I am hopeful I can create a library more user friendly than Scalaz (and with documentation!), and more category theory based than the current builders approach (which apparently is experiencing obscure corner cases, as I heard in the Paul Philips interview). I have some initial experimentation to give me a (weak) basis for that claim. This conflation of pattern matching (one of Scala's brilliant features) and the standard library, is a potential point of significant competitive weakness, as Gavin King is a library master and afaics (in the Ceylonlanguage design FAQ) is already demonstrating his pragmatism for user friendly design choices. I don't know how long it will take them to challenge Scala, but don't dismiss the exponential speed of a ramping community of huge pool of excited Java developers (against a dozen or so hard-core Typesafe developers). Exhibits: http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html (see my Modularity, Concurrency, Complexity comments) http://blog.joda.org/2011/11/scala-ejb-2-feedback.html http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist http://grahamhackingscala.blogspot.com/2011/12/will-typesafe-address-scala-criticisms.html
        Hide
        Shelby Moore III added a comment -

        Added some more rationale for prioritization in a mailing list post:

        http://groups.google.com/group/scala-language/browse_thread/thread/914f57421eeb503b

        Show
        Shelby Moore III added a comment - Added some more rationale for prioritization in a mailing list post: http://groups.google.com/group/scala-language/browse_thread/thread/914f57421eeb503b
        Hide
        Paul Phillips added a comment -

        As of 38d5b20374 some progress has been made in this direction. https://github.com/scala/scala/pull/2848

        Show
        Paul Phillips added a comment - As of 38d5b20374 some progress has been made in this direction. https://github.com/scala/scala/pull/2848

          People

          • Assignee:
            Unassigned
            Reporter:
            Shelby Moore III
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development