This is similar to the argument of "why not use let* everywhere you use let?" and there is no convincing answer IMO. I too am a big fan of pattern matching, and I would appreciate a #lang where every binding form is a pattern (ala ML, Haskell, ...). But in Racket as it exists today, I don't really use define/match because it adds a bit of clutter when a single "match" would suffice. If I had a cleaner version that was the default, I would definitely use it.
Every once in a while I am tempted to create a #lang that does nothing but reimplement the standard library functions and macros to be more to my taste, but it would be a considerable effort with marginal returns. On Monday, December 17, 2018 at 7:58:18 AM UTC-8, Will Jukes wrote: > > After learning more Haskell I've been playing around with match and > define/match, and I'm wondering if there's any particular reason to prefer > more traditional Scheme forms over match (I vastly prefer match in most > cases). Glancing at the match module it looks the process of expanding a > match clause is pretty intricate, and the documentation mentions that match > lacks the time complexity guarantee of case, but beyond that it's not > immediately clear whether match imposes some unacceptable overhead or etc., > or to what extent it does if so. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
