The difference is that there is tight integration between the editor and the REPL in Lisps. When I work with Clojure, my IDE is connected to the running application. I can inspect and reload any code in the application straight from the editor.

From what I understand stativ typing slow you too much

With python you can get a little bit closer using Jupyter, since it blends an editing environment with a REPL more than using iPython directly. I try to remember to use it instead of iPython when I need a REPL. It’s especially nice if you’re doing exploratory data work, because you can draw graphs and charts.

Smalltalk is strange you have not codesource file. Wonder about Julia

Ah, interesting.

Well, our normal macro system isn’t like Common Lisp style macros. It is strictly like syntax-rules from Scheme. That said, some pretty complicated things have been built with the standard Dylan macro system, like the binary-data library.

Inside the compiler however, we have an extended version of this macro system that does allow for quotation and such. I like it a lot and it is really powerful. It is how large parts of the compiler are actually written, including our C-FFI interface. If you check out the D-Expressions paper that I reference above, it deals with this pretty extensively, although some of what is discussed in the paper is not implemented (the parts about the module system).

It is an open project for someone to make it so that a project can have a compiler plugin that uses this macro system extension. I don’t know that it would be incredibly difficult. It would probably be challenging, and would almost certainly be enjoyable.

Inside the compiler, these special compiler macros are defined by define &macro rather than define macro. From there, they even start out looking like a regular macro, however, instead of the pattern matching and being used for template substitution (effectively), it is instead executing code which returns AST fragments. The compiler builds upon this and has &converter and other forms which just expand to &macro definitions and are key to how things go from the parsed tokens to the actual compiler IR, eventually.

That would all be quite tedious if one still had to construct AST stuff by hand, but thankfully, it works with quoting as well, using #{ ... } and allowing for substitution. Inside the compiler, one can use that to construct AST fragments. Unfortunately, these tend to be used in fairly complex areas, so I don’t have a really nice simple example.

define &macro c-address-definer
  { define c-address ?var-name:name :: ?pointer-designator:expression
      ?options:*;
    end }
    =>
  begin
    let initargs = parse-options($c-address-options, options, var-name);
    let options = apply(make, <c-address-options-descriptor>, initargs);
    let c-name = c-address-c-name(options);
    if (c-name)
      let import = c-address-import(options) | #{ #f };
      #{ define constant ?var-name
           = make(check-c-address-designator(?var-name, ?pointer-designator),
                  address: primitive-wrap-machine-word
                    (primitive-cast-pointer-as-raw
                       (%c-variable-pointer(?c-name, ?import)))) };
    else
      note(<missing-c-name>,
           source-location: fragment-source-location(form),
           definition-name: var-name);
      #{ };
    end if;
  end;
end &macro;

That one isn’t too difficult though and comes from our C-FFI. You can see that it defines a pattern to be matched, define c-address .... and then it executes some code to parse the options, some basic validation, and then it checks to be sure that a c-name has been provided in the options. If it has, it returns the quoted AST (define constant ?var-name ....). If it hasn’t gotten a c-name option, then it issues a compiler warning (note(<missing-c-name>, ...) and then returns an empty AST fragment (#{ }). That wasn’t too terrible! :)