Summary of piping/chaining proposal?

Internals & Design
21

Hey, super interesting! Can we read more about this proposal for macro traits somewhere?

At Pluto we once worked on a big list of “dummy macros” that emulate the behaviour of popular macros so that they could be analysed statically. In the end we went for a full dynamic analyser, but I think this static dummy system would help a lot of beginners using popular packages in LS editors like vscode.

22

I didn’t make a formal proposal – just spit balling in another Discourse thread. I’ll try to track it down! But my basic idea was some mechanism to tell VSCode/LanguageServer that it’s safe to run @macroexpand on certain macros when analyzing some code.

That could be done by:

  1. At call site, with a special comment (like Python’s # ignore type for silencing type hint warnings)
  2. A menu for selecting expandable macros in the VSCode sidebar, similar to the menu for selecting compiled symbols in the debugger.
  3. Using Preferences.jl or some other configuration format to keep a list of macros along side the code in the directory’s files.

Alternatively, it could be the job the macro implementor to define something like LanguageServer.is_pure_macro(::Type{MyMacro}) = true in an extension, but I like the idea of allowing the user to toggle this behavior. Also, a static analyzer wouldn’t have MyMacro rendered as a type but as a symbol. So that complicates the story for macro implementors setting a trait.

23

Can VSCode’s Notebook extension do that?

This could be a way, to bridge that.

24

I’m not much of a Jupyter user, so I really couldn’t say!

1 Like