Add enumerated types to macro language

[EvanKirshenbaum]

When modifying the OSU macros, Mike wrote

// mixing style 1 is to merge then split continuously, mixing style 2 is to merge
// then walk then split continuously 
combine_drops = macro(well outer, well inner, time mixing_time, int mixing_style) -> drop {

At the moment this is probably the best you can do, but it brings up a deficiency (actually, several) in the language.

The ones not covered here are

• You should be able to specify a default value for parameters (#160)
• What you really want to be able to do is pass in a macro that tells you how to mix (also #160):

  macro combine_drops(well outer, well inner, time mixing_time,
                     macro mixer(pad, dir, dir) -> drop) -> drop {
    ...
  }

But failing being able to specify macro parameters that are themselves macros, what you want is a user-defined enumerated type, that would allow you to say something like

mixing_style is one of just_mix, mix_then_walk;
combine_drops(well outer, well inner, time mixing_time, mixing_style) -> drop { ... };

The only thing that would be tricky about adding this (other than making sure it plays well with predicate query is expressions) is that it isn't obvious how you would put it in the grammar so that a general ID can be used as a param_type without screwing things up.

I can see two approaches, neither of which is great (or terrible):

1. Have the type definition rule add an entry into some table and put a semantic predicate on the base_param_type rule branch for ID that checks the table.
   • This would really only work if we restrict user-defined type definitions to global scope
   • It also breaks the split we currently have between the passes of the parser.
2. Require a keyword to precede or follow the name, e.g., mixing type.
   • The problem here is finding a keyword that feels right for all kinds of uses of enums.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 28, 2023 at 11:50 AM PST.