everything should be in a module

[kjx]

everything (or most things at least) should be in modules.

we shouldn't spec "graceObject" or "SuccessfulMatch" or whatever. we should put them in modules, and let dialects import them

[apblack]

I would love to get pattern-matching out of the core language and into a module. I don't know how to do that; that's why I opened issue #30.

I think that I know how to get numbers and strings out of the core and into a module, but if I were to try, would find that I probably don't.

To put graceObject into a module, we would need to put a way of saying inherits nothing into the core language. This seems like a reasonable way to go, though.

But in some ways this is intellectual masturbation. Our real concern should be to define a reasonable language for novices, not a minimal core language for PoPL. We keep on getting distracted by our language designer roots from the real urgency of making a language for teaching and using it for that purpose.

[kjx]

I don't think we can put pattern-matching into a module, not most of it anyway.

Numbers and strings have literals, they can't go out either.

To put graceObject into a module, we would need to put a way of saying inherits nothing into the core language. This seems like a reasonable way to go, though.

we can put it's name into a module "grace.graceObject" or "grace.nothing" if we want. All I meant in this issue to suggest that we should. Also this issue is low priority.

We keep on getting distracted by our language designer roots from the real urgency of making a language for teaching and using it for that purpose

my urgency for now is getting a spec out. When I notice things to fix, I'm listing them here, rather than just making shit up. I'd prefer not to have "graceObject" sitting in the core prelude, ditto collections, ditto IO, etc. So even "print" should probably go somewhere else and the standard prelude should bring it in.

[apblack]

I don't think we can put pattern-matching into a module, not most of it anyway.

I think that we can put most of it in a module. The part we can't is the language extension required to bind new names in a variable pattern. This is also the part that I don't understand and that is not described at all well in the spec. Do we really want to keep it?

Numbers and strings have literals, they can't go out either.

I think that they can. Number literals could translate to a request on

primitive.number(numberLiteral:PlatformString) -> Number

String literals could similarly translate to a request on

primitive.string(stringLiteral:PlatformString) -> String

(And these methods should be manifest, so that they can be executed at compile time.)

This pre-supposes a more primitive type PlatformString that has the same relationship to String as Lineups do to Lists: they have a small number of methods, not designed for general-purpose programming but sufficient to build the more general structure. For example, in an implementation on JavaScript, PlatformString might be Javascript's broken native Strings, which use multiple "characters" to represent non-BMP codepoints, and which support iteration but not indexing, and String might be Grace's better glyph-based or codepoint-based Strings.

I would warn that changing this stuff in minigrace is incredibly delicate. So, regardless of what we spec, minigrace might not support it in the foreseeable future. Even changing the name of the standard prelude to "standardGrace" turns out to be unreasonably difficult.

I would suggest that for this version of the spec, we don't distinguish between what is in the core and what is in the standard dialect. That could be a goal for a future version.

[kjx]

I would suggest that for this version of the spec, we don't distinguish between what is in the core and what is in the standard dialect.

I think it's now or never to make that distinction.

But, I mean, it's not as if we have any kind of type system or a reliable grammar do we?

[apblack]

I think it's now or never to make that distinction.

I'm not clear why you say that. It doesn't really affect users at all. It will affect others who want to implement Grace, and I hope that we can get some other implementors on board ... But don't you think that details like this can be negotiated with the implementors when we know who they are?

[kjx]

I think that distinction will be hard to introduce later if we don't do it now - isn't it a core feature of the language design that a lot of work should be done in dialects and the core should be just that - a core?

Actually I don't think it would be too hard to refactor the spec to separate that out - especially if we are going to move things around anyway. But the more there is in there, the more there will be to move

[kjx]

we would need to put a way of saying inherits nothing into the core language.

Won't inherits done do the job?

[apblack]

done has an asString method. And it's important that it keep it, to get a reasonable error message when the student does something to done unintentionally.

[kjx]

done has an asString method.

yes but should it? #49 (Have notes from a discussion last week yet to write up; may do so later today)

And it's important that it keep it, to get a reasonable error message when the student does something to done unintentionally.

surely any error message has to deal with the fact that asString might break, so you have to be ready to fall back reflexively anyway. Once you've done that, done can have no methods, and any truly empty object stands for done

https://github.com/gracelang/language/issues/39#issuecomment-183551871