Hello, and thank you for your response.

I never intended to suggest that adding pattern matching would allow Go
computational capabilities that it did not previously have. I agree that
switch can be wielded to achieve the same logic in a syntax and structures
that roughly resembles my suggestion. Let me attempt to explain my actual
reasoning behind this proposal.

Imagine that I am building a lexer, a parser or a compiler. If I am to
follow your syntax, I would need to repeat a variant of this line from your
example quite a few times: day, date := getDayAndDate()

That indicates the necessity of declaring and allocates variables -- the
memory pollution is secondary to the namespace and code elegance pollution
there -- quite often throughout my code as it goes through the AST or
whatever else structure I could be considering. In pattern matching the
`day` and `date` variables *are not declared unless used for purposes other
than pattern matching*: if I needed them, I'd write: `x, y:`, otherwise I'd
write `"tuesday", 5:`.

In addition to the above I would then very likely need to have nested ifs
within nested ifs -- and dealing with each potential pattern that I'm
trying to match would necessitate so much cruft that the resulting code
would be very ugly. Indeed it's my view that Golang is currently not a
suitable language for expressing any program that involves the treatment of
an AST due to these syntactic limitations, i.e. the lack of real pattern
matching.

It's true that in the examples we're discussing, this pollution is minimal,
but that's because they're simple examples. In the context of more complex
parsing or transpiling, using switch as it currently is causes the code to
become quite cumbersome, repetitive and nested. It's really a huge problem
when dealing with actual languages and I can say that from experience.

I agree that the `if` guard in my third original example is superfluous, so
let's put it aside. I would still like to argue for the `match` keyword
because I think that aside from the infinitely more elegant method and
syntax for pattern matching, the benefits of wildcards (expressed with `_`)
and also of struct type deconstruction (as seen in my third original
example). I believe that `_`s are already ubiquitous around Golang and are
used amply for very similar purposes as the ones they'd be used for here.

This indeed could be a new direction for Go to consider, I don't claim to
know. I don't mean to step on anyone's toes here or to dictate what the
language should look like. I just sincerely think that `match` would make
Golang a better language, not by allowing it to strictly *do things* it
couldn't do before, but to do *a class of things elegantly* whereas it
couldn't do them elegantly before.

Nadim
Sent from my computer


On Wed, Jun 5, 2019 at 4:07 PM Ian Lance Taylor <i...@golang.org> wrote:

> On Tue, Jun 4, 2019 at 10:22 PM Nadim Kobeissi <nadim@nadim.computer>
> wrote:
> >
> > Two more examples to show off some more cool ways match could be useful.
> Here, I just demonstrate how we can have logic inside matches thanks to
> anonymous functions:
> >
> > result = match getDayAndDate() {
> >     "tuesday", _: "wow looks like it's tuesday",
> >     _, 5: (func() string {
> >         if isItWednesday() == true {
> >             return "well, at least it's wednesday!"
> >         } else {
> >             return "not wednesday either!"
> >         }
> >     })(),
> > }
> >
> > Here's another interesting example which showcases destructuring as well
> as guards:
> >
> > type date struct {
> >     day   int
> >     month string
> >     year  int
> > }
> >
> > func getDate() date { /* Use your imagination */ }
> >
> > var today string
> >
> > today = match getDate() {
> >     date{day: d, month: m, year: y} if (m == 2) && (d > 29) :
> fmt.Sprintf("Today is impossible.", m, d, y),
> >     date{day: d, month: m, year: y}: fmt.Sprintf("Today is %s %d, %d.",
> m, d, y),
> > }
>
> There are a lot of complex ideas being mixed together here.  Let me
> try to write these examples in the existing language.
>
> result = func() string {
>     day, date := getDayAndDate()
>     switch {
>     case day == "tuesday":
>         return "it's Tuesday"
>     case date == 5:
>         if isItWednesday() == true {
>             return "well, at least it's wednesday!"
>         } else {
>             return "not wednesday either!"
>         }
>     }
>     return ""
> }()
>
>
> today = func() string {
>     d := getDate()
>     switch {
>     case d.month == 2 && d.day == 29:
>         return fmt.Sprint("Today is impossible.", d.month, d.day, d.year)
>     default:
>         return fmt.Sprintf("Today is %s %d, %d.", d.month, d.day, d.year)
>     }
> }()
>
> The code with match is a little shorter, but it doesn't seem to
> provide any capability that we don't already have.  Any new language
> feature of this complexity should be orthogonal to other features.  To
> my eyes match seems to have a significant overlap with switch.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK-38xW91-o5qCGZ5dPU-HsQZv74%3D_i2QA%3DuTy%2B8_jD3d04FGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to