Unknown, None, etc are not reserved

[apblack]

According to the spec, Unknown is not a reserved word. I think that it should be.

Unknown is an essential part of Grace's type system. Doesn't that make it an essential apart of the language? We can't define Unknown in Grace, so I don't see how it can be an identifier introduced in the prelude.

If it's not reserved, then it can be redefined. If it can be redefined, how does one reference the "real" Unknown?

The exact type-matching rules that a dialect applies to Unknown may be up to it, but the fact that omitted type arguments are replaced by Unknown tells me, I think, that Unknown has to be defined!

We need a decision on this to resolve issue gracelang/minigrace#290.

[KimBruce]

I agree that it should be reserved.

[IsaacOscar]

Definitely, everything "magical", like Self, Unknown, None, self and outer should either be reserved, or else there should be a standard way of accesing the magical versions if somone tries to override them. E.g. $Unknown could be a keyword, and then standard grace just defines an alias type Unkwnon = $Unknown, that can then be ovveriden (like C does with _Bool/bool).

[apblack]

Let's make Unknown reserved. I think that @IsaacOscar is correct that None should be reserved too, since we can't define None in Grace either.

[kjx]

since we can't define None in Grace either.

no, but we could put them in intrinsics or somewhere and have our own defs get them from there, rather than reserve the names...

[apblack]

What I can do in a Grace module is to define noneType to be an object with type Type and with the appropriate behaviour , and then say

type None = noneType

This works in minigrace because the compiler doesn't distinguish type expressions from value expressions. But arguably, that's a minigrace bug, and not something we should be relying on.

What we can't do in any Grace module is to define None, because the type syntax doesn't let us express a type with an infinite number of methods.

This prompts the question: is intrinsics magic, or is it a Grace module?

[kjx]

On 29/10/2019, at 7:46AM, Andrew Black notifications@github.com wrote:

But arguably, that's a minigrace bug, and not something we should be relying on.

or it's not a bug - it's the future!

https://michael.homer.nz/Publications/DLS2019/pattern-types.pdf

James

[apblack]

Unknown is now a reserved word. None is not, and I'm not sure if it should be, so I'll leave this issue open.

[apblack]

I've been thinking about this again. How do we determine what should be reserved, and therefore a part of the language itself, versus what should not be reserved, but instead defined in a dialect? Can we find a general rule, rather then deciding on a case-by-case basis?

Is Grace's type system "part of the language", or can we imagine several different type systems? I guess that we do have two type systems already: a static type system implemented by Kim's type-checking dialect, and the dynamic type system implemented as part of minigrace. Is None part of both of these? Is it a part of any conceivable type system? Does None have the same value in any conceivable type system? If the answer is "yes" to all of these questions, perhaps this means that None should be reserved as part of the language?

[apblack]

Done and done raise a similar issue. The spec says that "Assignments, and methods without an explicit result, have the value done, of type Done". Hence, the value done is part of the language. Does that mean that done should be reserved? But Done should not be, because a dialect might have no such type? (In minigrace, both done and Done are predefined identifiers, but not reserved.)

If we were just language lawyers, we might argue that the spec saying that assignments return done does not imply that there has to be a pre-defined constant written done. But we are trying to educate beginning programmers, not train lawyers. What would a beginner expect?

[KimBruce]

Because of the prime focus on education, an important principle should be one of "no unnecessary surprises". Because "done" is returned as a value by assignments (even though few programmers would use it), there should not be another visible identifier with a different meaning there to confuse a programmer (even if only through debugging print statements). Thus they should be reserved words. I would argue that "Done" should be handled similarly. "None" and "none" are less likely to come up in practice, but I'd argue making them reserved is more consistent than not making them reserved.

Semi-relevant anecdote: When I started teaching programming we had to use FORTRAN. One day a student brought me a program that kept giving wrong results even though everything looked fine. A greatly simplified version of the procedure they had written looked something like (though I'm sure the syntax is wrong). PROCEDURE CHGTO4(N) N = 4 END

Later in the program was a call to the routine, CHGTO4(2).

Of course everything was more convoluted (it was a student program after all), so I hadn't noted the absurd call of the routine.

Eventually I wrote enough test code to discover that after the call to the routine, the value of the constant 2 was now 4. Of course this made no sense until I realized that FORTRAN kept constant definitions in a static part of memory. So the value of "2" was kept in a storage location, L. When the call CHGTO4(2) was called (via call-by-reference of course), the value in location L was changed to 4, which was then used as the value of 4 for the rest of the program. This obviously was a very bad compiler decisions and later compilers fixed the issue. However, the moral is that constants really should always have the same value. While it's pretty extreme to change the value of "2" to "4", I would argue that "done", as a constant, should also not change values!

On Thu, Dec 29, 2022 at 9:58 AM Andrew Black @.***> wrote:

Done and done raise a similar issue. The spec says that "Assignments, and methods without an explicit result, have the value done, of type Done". Hence, the value done is part of the language. Does that mean that done should be reserved? But Done should not be, because a dialect might have no such type? (In minigrace, both done and Done are predefined identifiers, but not reserved.)

If we were just language lawyers, we might argue that the spec saying that assignments return done does not imply that there has to be a pre-defined constant written done. But we are trying to educate beginning programmers, not train lawyers. What would a beginner expect?

— Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/178#issuecomment-1367494624, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN2D6TC4Z5SMCEURIX3HMDWPXGMHANCNFSM4HWXATMQ . You are receiving this because you commented.Message ID: @.***>

-- Prof. Kim Bruce Computer Science Pomona College

[kjx]

On 30/12/2022, at 09:57, Kim Bruce @.***> wrote:

Semi-relevant anecdote: When I started teaching programming we had to use FORTRAN.

believe it or not, I did much the same in Smalltalk, way back when:

[apblack]

I don’t know how to do that in Smalltalk. This just confirms what we already knew: my limited imagination.

None is uninhabited, so there is no value none. Other than that, I agree with @KimBruce about the principle of least astonishment. But we also have a minimality principal that says that we shouldn’t put things into the core language that could just as easily be defined in a dialect (such as standard). For Done and done, these principles seem to conflict.

I suppose that we could resolve the conflict by defining them in the standard dialect, and also having the dialect prohibit their re-definition.

[KimBruce]

Making it reserved seems simpler and more "graceful".

On Fri, Dec 30, 2022 at 8:24 AM Andrew Black @.***> wrote:

I don’t know how to do that in Smalltalk. This just confirms what we already knew: my limited imagination.

None is uninhabited, so there is no value none. Other than that, I agree with @KimBruce https://github.com/KimBruce about the principle of least astonishment. But we also have a minimality principal that says that we shouldn’t put things into the core language that could just as easily be defined in a dialect (such as standard). For Done and done, these principles seem to conflict.

I suppose that we could resolve the conflict by defining them in the standard dialect, and also having the dialect prohibit their re-definition.

— Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/178#issuecomment-1367994754, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN2D6RQHFN5JJRMBI5EM7LWP4EEXANCNFSM4HWXATMQ . You are receiving this because you were mentioned.Message ID: @.***>

-- Prof. Kim Bruce Computer Science Pomona College