Ted Kaminski

As another aspect of this, I believe we should have the ability to place function into the "dot scope" of any type. That is, we should be able to define...

This might merit being a separate issue, but I'm going to dump it here, because it's relevant to the idea that in the future we might have `import x:y;` not...

The analog here is Java and other JVM hosted languages. `java.lang` is visibile by default. Then you import `java.util.datastructure` or `java.lang.io` or `java.time` etc. It's a question of namespace ownership....

Getting that kind of change in for 0.4 is unlikely. We're mostly last-minute scrambling to get the bare minimum done for it as usual. In the other referenced thread, I...

I think I'm swayed over to just `silver:json`. 1. It avoids having to come up with some extra naming scheme. 2. It shouldn't be too hard to emphasize the things...

Some thoughts on dependencies. I was envisioning these artifacts: ``` silver.compiler-1.0.0.jar silver.lang-1.0.0.jar silver.util-1.0.0.jar silver.langutil-1.0.0.jar ``` Each of these artifacts can ship multiple grammars, of course, beneath the top-level namespace the...

> When you mention reflect here, are you referring to what is now core:reflect or what is now silver:reflect? Once we have an artifact system like this, they could likely...

Ah. Not separate artifact. Merged into the same grammar in the `silver.lang` artifact.

> Do you mean merging both core:reflect and silver:reflect into a silver:lang:reflect grammar that is distributed as part of the silver.lang artifact? Yep. > That would make silver.lang depend on...

With the artifacts approach, it wouldn't be a problem for that parser to be in `silver:lang:reflect` since it'd be distributed in already compiled form, and it doesn't create any extra...