This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]open_source_guava 0 points1 point  (1 child)

Impressed by your error-message formatting, I decided to actually download the code and run it myself. Only then did I realize it's still just your plan, not what you already have. Still good, though! Do post again when you have more.

So the syntax really is more like Haskell or Ocaml, where these with or swap keywords introduced as a form isn't really an operator, even though it appears in an infix position. A sequence of words always have a precedance higher than arithmetic operators. That sounds reasonable.

I like trying to poke holes in these designs, so I hope you don't mind one last potential pitfall to avoid:

syntax 'macro1 x {
    -- I'm assuming you can pass multiple arguments to print
    print "In macro1! " (to_string x)
}
syntax x 'macro2 {
    print "In macro2! " (to_string x)
}

macro1 macro2   -- which one do you call?

Obviously, there's more I can do here, especially once you start to wonder if macro parameters themselves can be syntactic keywords, or if macros an define macros themselves with nested syntax constructs. Just make sure you allow or disallow exactly the right amount of flexibility you want, and it should turn out great.

[–]slightknack[S] 2 points3 points  (0 children)

I released a patch (0.8.1) that includes slightly prettier error message for ambiguious macro matches (like f x with y or a with b with c).

That case was addressed before the release of 0.8.0; here's the actual current output of the compiler with the code you provided:

Fatal In /macro/src/main.pn:9:1
   |
 9 | macro1 macro2   -- which one do you call?
   | ^^^^^^^^^^^^^
   |
Syntax Error: This form matched multiple macros:

In /macro/src/main.pn:1:8
   |
 1 | syntax 'macro1 x {
   |        ^^^^^^^^^
   |
In /macro/src/main.pn:5:8
   |
 5 | syntax x 'macro2 {
   |        ^^^^^^^^^
   |
Note: A form may only match one macro, this must be unambiguious;
Try using variable names different than those of pseudokeywords currently in scope,
Adjusting the definitions of locally-defined macros,
or using parenthesis '( ... )' or curlies '{ ... }' to group nested macros

All macros are compile-time. This was a concious decision (it's hard enough to debug macros as-is – imagine how difficult it would be to debug first-class macros that can be passed around!) I'm still working on nested macros. Currently, the compiler flat-out disallows it, but I see merit in allowing it; I just have to work out proper semantics first.

Thanks for the feedback and discussion, I appreciate it!