10 ms·

Patten Matching in Nim

145 points by haxscramper 6y ago

haxscramper 6y ago
Using nim pattern matching library to implement simple dataflow programming DSL.
elcritch 6y ago
Exciting! I look forward to trying it out. Having macros in Nim really does make it so much easier to extend. The writeup on writing a macro based DSL in Nim seems handy. Mostly I use the `template` form of simplified macros that cover most meta programming needs along with `const` and compile time execution. Nim has a full VM, so almost any codecan run at compile time. There's also a new library for 2d graphics being written and figma like UIs: https://forum.nim-lang.org/t/7559 https://forum.nim-lang.org/t/7559 I'm hoping items like the DSL help people write more interesting Nim libraries.
hbbio 6y ago
s/Patten/Pattern/
- _0ffh 6y ago
  @Dang Yes, that would be nice! Could you, please?
- amelius 6y ago
  Pattern matching to the rescue!
flywind 6y ago
Great article!
deleted 6y ago
[deleted]
sergiotapia 6y ago
As an Elixir developer who uses Nim for love of the language this is very exciting!
pietroppeter 6y ago
very well done, looking forward to use it! related discussion in nim forum (started because I had question about fusion): https://forum.nim-lang.org/t/7608 https://forum.nim-lang.org/t/7608 if this keeps staying in front page, maybe it makes sense for @dang to fix the typo in the title (Patten -> Pattern)
nonsince 6y ago
The amount of power that Nim has is absolutely obscene. I don't really have a good use-case for it right now, but it's a language that I know I'd enjoy if I got into it.
- amelius 6y ago
  Does Nim solve the "what color is your function" problem?
  - dwohnitmok 6y ago
    That's kind of not a language-level thing. I mean it is, but it's tied very very closely to runtime choices rather than the language itself. Basically your question is equivalent to asking whether the language has green threads. The original article describing color (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...) says it's just threads, but it glosses over why a language like C# decided to add async-await and why Java now has its ongoing Loom project. System threads are heavyweight and as a result usually unsuitable as your concurrency primitive for highly concurrent applications (although you can and most runtimes do build on top of threads). And so if you only have that, you inevitably get what the article calls the "color problem" (see e.g. in Java the async IO APIs, which the article laments, but doesn't explore why they exist and moreover are often preferred by Java programmers over their synchronous equivalents), because system threads aren't enough and a color-based solution inevitably must appear on top of them. So the question to ask is "does Nim have green threads?" To which the answer is no (and then by extension it does have the color problem, in this case via async-await).
  - rattray 6y ago
    Fwiw I personally quite like having function colors for async tasks and I/O, and in fact wish we also had them for purity (both read-purity and write-purity).
  - rattray 6y ago
    > The await keyword can only be used inside procedures marked with the {.async.} pragma. https://livebook.manning.com/concept/nim/await https://livebook.manning.com/concept/nim/await
cb321 6y ago
The pattern matching blog post is indeed great (good job @haxscramper!). Casual Nim observers might want to click on the Blog link at the top (Or all the other links!). There have been quite a few posts in the past year or so on ARC & ORC garbage collection, multi-threading run-times, and a variety of "overview posts" on a lot of various happenings.
tiffanyh 6y ago
NIM seems like this unicorn of a language of having great performance, amazing balance between being both high-level and low-level, extremely approachable due to syntax ... yet very few have actual discovered and use NIM. I wonder why.
- nimmer 6y ago
  ...because nowadays the world of software is marketing driven. People often ask me what big company is behind Nim even before asking about its design and features.
- gilrain 6y ago
  In my case, I actually prefer my languages to be more opinionated. Nim implements just about every paradigm it can think of, and if there are multiple ways to implement a paradigm, it implements them all. It feels like a sophomore college student who keeps switching majors. Some people prefer "There is Only One Way to Do It" languages. Some people prefer "There is More Than One Way to Do It" languages. Nim is more like a "There Are Seven Ways to Do It and the Eighth Way is Planned" language.
  - cb321 6y ago
    Nim is a very flexible language where things that would, in almost any other language (besides Lisp/Racket/etc) require direct compiler support (like async/coloring) can be done as libraries. Consequently, people disagreeing the way they do in their opinions, even if there were not seven ways to do something in the core language/stdlib, libraries would add those ways. So, the ecosystem would still have them all and more (eventually). Personal opinion, but I would say Nim is remarkable in being able to support & manage all this diversity. One does not see Nim style guides like C++ style guides where you are only supposed to use the 5..10% or whatever of the specified language that everyone on a team understands, for example. { Yet! Famous last words... :-) }
  - pietroppeter 6y ago
    Nim seems pretty opinionated to me: use imperative style, minimal or none OOP (preference for macro built DSLs over OOP), functional allowed for those who like it. Also looking code around I think style and usage is pretty consistent and Nim idiomatic code is certainly a thing. Overall I think it is a definitely consistent language. It is definitely evolving but you can go a long (loong way) with 1.0 features. I also believe “there is only on way to do it” is more of a slogan/goal than a real thing.
salamanderman 6y ago
I played with Nim a little bit, loving it for a while, and I quickly ran into the same issue I had with Julia, which was that I had trouble staying in the basic language. Both Nim and Julia's documentation, and many modules/imports/includes/whatever of those languages, immediately jump to "holy shit we have macros! Importing this module changes the syntax! Isn't that awesome?!" And I'm like, no, it's not awesome. New syntax, new syntactic sugar, etc. is a learning curve every time for me. I'm often skeptical of operator overloading in C++ and python, so macro crazy languages are even worse. I feel like I must be in the minority, or I haven't hit that programming nirvana.
- sergiotapia 6y ago
  I totally agree with you, that's why I started Nimlings to help new Nim engineers get familiar with the language. Let's face it, you probably won't need macros WELL into your Nim lifecycle. https://github.com/sergiotapia/nimlings https://github.com/sergiotapia/nimlings
- planetis 6y ago
  ...except that macros don't change the syntax of the language! They just offer convenience on top of it, most common example is the `=>` lambda operator from the `sugar` module. I do agree, that the pattern matching macro presented in the article is a bit hard to get used to, but you don't have to, if you don't like pattern matching. And of course there are plenty of alternatives available as well, the simplest one imo is https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty
- nimmer 6y ago
  In all non-trivial codebases you have to learn how other people implemented something. It can be easy or take time depending on the how well it's written. Macros are not different than functions: one can create readable or crazy spaghetti code in any language. If you find a codebase full of unreadable macros it's not different than any other type of bad code: stay away from it or simplify it. Personally, I'm yet to find a macro that makes the code less readable or more difficult to understand.
- dukeyukey 6y ago

145 points by haxscramper 6y ago

Using nim pattern matching library to implement simple dataflow programming DSL.

Exciting! I look forward to trying it out. Having macros in Nim really does make it so much easier to extend. The writeup on writing a macro based DSL in Nim seems handy. Mostly I use the `template` form of simplified macros that cover most meta programming needs along with `const` and compile time execution. Nim has a full VM, so almost any codecan run at compile time. There's also a new library for 2d graphics being written and figma like UIs: https://forum.nim-lang.org/t/7559 https://forum.nim-lang.org/t/7559 I'm hoping items like the DSL help people write more interesting Nim libraries.

hbbio 6y ago

s/Patten/Pattern/

_0ffh 6y ago
@Dang Yes, that would be nice! Could you, please?
amelius 6y ago
Pattern matching to the rescue!

flywind 6y ago

Great article!

deleted 6y ago

[deleted]

sergiotapia 6y ago

As an Elixir developer who uses Nim for love of the language this is very exciting!

pietroppeter 6y ago

very well done, looking forward to use it! related discussion in nim forum (started because I had question about fusion): https://forum.nim-lang.org/t/7608 https://forum.nim-lang.org/t/7608 if this keeps staying in front page, maybe it makes sense for @dang to fix the typo in the title (Patten -> Pattern)

nonsince 6y ago

The amount of power that Nim has is absolutely obscene. I don't really have a good use-case for it right now, but it's a language that I know I'd enjoy if I got into it.

amelius 6y ago
Does Nim solve the "what color is your function" problem?
- dwohnitmok 6y ago
  That's kind of not a language-level thing. I mean it is, but it's tied very very closely to runtime choices rather than the language itself. Basically your question is equivalent to asking whether the language has green threads. The original article describing color (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...) says it's just threads, but it glosses over why a language like C# decided to add async-await and why Java now has its ongoing Loom project. System threads are heavyweight and as a result usually unsuitable as your concurrency primitive for highly concurrent applications (although you can and most runtimes do build on top of threads). And so if you only have that, you inevitably get what the article calls the "color problem" (see e.g. in Java the async IO APIs, which the article laments, but doesn't explore why they exist and moreover are often preferred by Java programmers over their synchronous equivalents), because system threads aren't enough and a color-based solution inevitably must appear on top of them. So the question to ask is "does Nim have green threads?" To which the answer is no (and then by extension it does have the color problem, in this case via async-await).
- rattray 6y ago
  Fwiw I personally quite like having function colors for async tasks and I/O, and in fact wish we also had them for purity (both read-purity and write-purity).
- rattray 6y ago
  > The await keyword can only be used inside procedures marked with the {.async.} pragma. https://livebook.manning.com/concept/nim/await https://livebook.manning.com/concept/nim/await

cb321 6y ago

The pattern matching blog post is indeed great (good job @haxscramper!). Casual Nim observers might want to click on the Blog link at the top (Or all the other links!). There have been quite a few posts in the past year or so on ARC & ORC garbage collection, multi-threading run-times, and a variety of "overview posts" on a lot of various happenings.

tiffanyh 6y ago

NIM seems like this unicorn of a language of having great performance, amazing balance between being both high-level and low-level, extremely approachable due to syntax ... yet very few have actual discovered and use NIM. I wonder why.

nimmer 6y ago
...because nowadays the world of software is marketing driven. People often ask me what big company is behind Nim even before asking about its design and features.
gilrain 6y ago
In my case, I actually prefer my languages to be more opinionated. Nim implements just about every paradigm it can think of, and if there are multiple ways to implement a paradigm, it implements them all. It feels like a sophomore college student who keeps switching majors. Some people prefer "There is Only One Way to Do It" languages. Some people prefer "There is More Than One Way to Do It" languages. Nim is more like a "There Are Seven Ways to Do It and the Eighth Way is Planned" language.
- cb321 6y ago
  Nim is a very flexible language where things that would, in almost any other language (besides Lisp/Racket/etc) require direct compiler support (like async/coloring) can be done as libraries. Consequently, people disagreeing the way they do in their opinions, even if there were not seven ways to do something in the core language/stdlib, libraries would add those ways. So, the ecosystem would still have them all and more (eventually). Personal opinion, but I would say Nim is remarkable in being able to support & manage all this diversity. One does not see Nim style guides like C++ style guides where you are only supposed to use the 5..10% or whatever of the specified language that everyone on a team understands, for example. { Yet! Famous last words... :-) }
- pietroppeter 6y ago
  Nim seems pretty opinionated to me: use imperative style, minimal or none OOP (preference for macro built DSLs over OOP), functional allowed for those who like it. Also looking code around I think style and usage is pretty consistent and Nim idiomatic code is certainly a thing. Overall I think it is a definitely consistent language. It is definitely evolving but you can go a long (loong way) with 1.0 features. I also believe “there is only on way to do it” is more of a slogan/goal than a real thing.

salamanderman 6y ago

I played with Nim a little bit, loving it for a while, and I quickly ran into the same issue I had with Julia, which was that I had trouble staying in the basic language. Both Nim and Julia's documentation, and many modules/imports/includes/whatever of those languages, immediately jump to "holy shit we have macros! Importing this module changes the syntax! Isn't that awesome?!" And I'm like, no, it's not awesome. New syntax, new syntactic sugar, etc. is a learning curve every time for me. I'm often skeptical of operator overloading in C++ and python, so macro crazy languages are even worse. I feel like I must be in the minority, or I haven't hit that programming nirvana.

sergiotapia 6y ago
I totally agree with you, that's why I started Nimlings to help new Nim engineers get familiar with the language. Let's face it, you probably won't need macros WELL into your Nim lifecycle. https://github.com/sergiotapia/nimlings https://github.com/sergiotapia/nimlings
planetis 6y ago
...except that macros don't change the syntax of the language! They just offer convenience on top of it, most common example is the `=>` lambda operator from the `sugar` module. I do agree, that the pattern matching macro presented in the article is a bit hard to get used to, but you don't have to, if you don't like pattern matching. And of course there are plenty of alternatives available as well, the simplest one imo is https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty
nimmer 6y ago
In all non-trivial codebases you have to learn how other people implemented something. It can be easy or take time depending on the how well it's written. Macros are not different than functions: one can create readable or crazy spaghetti code in any language. If you find a codebase full of unreadable macros it's not different than any other type of bad code: stay away from it or simplify it. Personally, I'm yet to find a macro that makes the code less readable or more difficult to understand.
dukeyukey 6y ago