search

gelisam / klister

an implementation of stuck macros
BSD 3-Clause "New" or "Revised" License
134 stars 11 forks source link

Set of problems should be open-ended #216

Open gelisam opened 1 year ago

gelisam commented 1 year ago

Currently, the kernel language defines a Problem datatype which lists a small number of problems which the macro might currently need to solve, such as an expression, a type, or a pattern. It would be nice to allow libraries to extend this list.

For example, imagine an extensible library which provides pattern guards and allows the user to define variants, such as view patterns. The library must define a convention, which the user must follow when writing macros which cooperate with the library. The convention could be:

  1. the current Problem is an expression
  2. you can expect the scope to contain scrutinee, on-success, and on-failure
  3. to make a variable available to the RHS of the branch, generate a let which binds that variable and call on-success within the body of the let
  4. to try the next pattern, generate a call to on-failure

Thanks to this convention, it is now possible for the user to write a macro which cooperates with this library... But consider a macro like list, which makes sense in an expression context as well as a pattern context. Wouldn't it make sense to also allow list to cooperate with the pattern guard library? Alas, it cannot, because which-problem will return the same value, (expression _), in two of those three contexts. If the library could extend the list of possible problems, e.g. to add fancy-pattern, then list could distinguish between those two contexts.

gelisam commented 1 year ago

Here is one possibility.

Once we implement #105, we could scrap which-problem and instead define separate syntax parameters indicating whether the current context is X or not. So the (current-expression-type) syntax parameter would provide a (Maybe Type), the (current-pattern-context) syntax parameter would return a (Maybe Unit), and the library could define a (current-fancy-pattern-context) syntax parameter of type (Maybe (Syntax, Macro Syntax, Macro Syntax)), to explicitly provide scrutinee and the continuations to the user's macro.

One difficulty with that approach is that setting the other syntax parameters to Nothing only a convention, and one which is hard to follow if different libraries can define different syntax parameters and don't know about each other. So maybe the kernel should provide a facility for registering a syntax parameter and setting all the registered syntax parameters to Nothing?