Skip to content

Instantly share code, notes, and snippets.

@baroquebobcat
Last active December 11, 2015 10:38
Show Gist options
  • Select an option

  • Save baroquebobcat/4588327 to your computer and use it in GitHub Desktop.

Select an option

Save baroquebobcat/4588327 to your computer and use it in GitHub Desktop.
Mirah Classloading

really need to think of there being 2 environments:

  • compiler
  • compilee/compilation/something

compiler includes all the compiler's bits like

  • Parser (AST, etc)
  • Typer
  • Intrinsics, Base Extensions
  • User Extensions.

compilee classpath has all the dependencies necessary to build against

  • bootclasspath, for LejOS and other alternate JVM implementations
  • classpath for library dependencies
  • classpath for previously built mirah bits
    • this is a little crazy when macros enter the picture because then it also needs to be on the compilers classpath too. If those macros reference dependencies that could get annoying.

User Extensions make me wonder if having an optional, separate macro classpath makes sense. Then you could say, my app has these dependencies, but compiling it has these additional dependencies. Maybe then it'd make sense to be able to have a separate build destination for macros to keep the shipped code clean. Or, we could just make a task for ripping out $Extensions classes as part of a final clean build.

@ribrdb

ribrdb commented Jan 22, 2013

Copy link
Copy Markdown

I've been thinking about this too. I'm about finished porting the code generator to mirah, then the next thing to tackle is the type system.
I think there needs to be a separate classpath for loading builtins.
And the macro classpath and a separate macro build output sound good too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment