This is leaving a comment for another programmer, not the compiler or interpreter. It's what comments are for, actually, like writing a TODO.

You should be squeamish about running the code without reading it first, given that you're pair-programming with a bot.

> You should be squeamish about running the code without reading it first, given that you're pair-programming with a bot.

It's funny, the first version of this project[0] let you do exactly that, e.g.,

  def main(path: str):
      #<<filenames = a list of filenames under path>>
  
      for fn in filenames:
          #<<size = size of fn in bytes>>
  
          print(fn, size)
  
  #<<use argparse and call main>>

and then run that program like any other Python script (using import magic):

  $ python -m examples.file_sizes /etc
  …
  /etc/wgetrc 4942
  /etc/nsswitch.conf 542
  /etc/adduser.conf 3028
  /etc/ethertypes 1816

But yeah, it never felt exactly practical. :)

[0] https://github.com/bsilverthorn/maccarone/tree/v0.1.3

Here is a framework which uses decorators to delegate runtime behavior to an LLM. Not quite what you meant but the closest I’ve seen.

https://askmarvin.ai/components/ai_function/

Decorators are a runtime construct, this is a code-writing-time feature, wouldn't it be confusing to have Maccarone find the decorators at write-time that then did nothing at runtime?

There are examples of decorators having no runtime effects, such as typing.overload. Bit comments are probably more flexible here since it allows arbitrary blocks, not just function/class scopes.

How would not having the source code be present/pre-generated, and thus needing to generate it at runtime, be an example of a decorator having no runtime effects?

I had the urge to try this out a while back, here's what I came up with: https://gist.github.com/nkrumm/2b154ea2041511233079222373c83...

The decorator invokes AI completion only the first time the function is run.

edit: I lost interest before I was able to get arguments to work ¯\_(ツ)_/¯

Yea, that’s cool and very possible, but it’s a runtime effect

OP has to be doing some parsing somewhere, so you just switch to seeking decorators rather than magic comments. It's still before the code reaches the interpreter.

The potential issue I see here is that comments are valid anywhere while decorators may not be, but the parser is hopefully resilient to that. You could see a multi-phase LLM that uses the interpreter to ensure the code runs / works as expected

It literally just adds the code to the file between the comments. There’s nothing more magic than copy+paste and no runtime component.

It’s completely different from a decorator that generates code at runtime? As in, when the code runs?

which comments should be generated?

what if the output has comments?

in my question, there is no need for the decorator to be handled at runtime, the tool that does the LLM stuff has to parse the Python code to know what to generate. It can just key off of decorators rather than comments, or at least this is my question & hypothesis.

I’m not objecting to what you say. The latter part of my comment is simply considering cases where you only want to replace a part of the function (the author have some examples on the project page), where a decorator wouldn’t be flexible enough to support. Of course you can also argue those can be easily rewritten to be function scoped, but that is a design tradeoff you make that author did not (or didn’t want to).

I guess comments provide a simple paradigm for many languages

comments are in most languages, so I can see that angle, but you still have to be able to parse all supported languages, no small feat

you can alternatively split generated code from human written code with files, keep the mapping in something more structured like a config file

I just normally see a better way to do the same thing a magic comment does, generally speaking. There is typically a better language construct if you limit yourself to that language (most common), and config files offer much more structure with existing tooling (mostly decode in your preferred language)