Whither "Builtins"?

[apblack]

It seems clear that some aspects of any implementation of Grace, like Numbers, Strings, and certain exceptions, and probably for(_)do(_) and if(_)then(_)elseif(_)...else(_) will beed to be "built in" rather than being defined in a prelude that is itself a Grace module.

How are such built-in methods accessed? Are they inherited by a prelude, implicitly or explicitly? Are they declared in an enclosing scope, surrounding the current prelude? Or what?

In minigrace, the identifierresloution pass assumes that there is a built-in scope that surrounds the prelude, but the code generators don't implement that. Hence, outer.outer at the top level is treated as legal, but crashes. I want to know the right way to fix this!

[kjx]

On 12/10/2016, at 4:37AM, Andrew Black notifications@github.com wrote:

It seems clear that some aspects of any implementation of Grace, like Numbers, Strings, and certain exceptions, and probably for()do() and if()then()elseif()...else() will beed to be "built in" rather than being defined in a prelude that is itself a Grace module.

depends how aggressive the implementation is. I think Self ran with its own definitions for if:Then: and friends; there was a primitive _Restart used for loops, because Self's spec forbade tail recursion elimination. We've never talked about that question, if we allowed it perhaps loops could be native too

How are such built-in methods accessed. Are the inherited by a prelude, implicitly or explicitly? Are declared in an outer scope outside of the current prelude? Or what?

I'm tempted to say "implementation detail" but that would eventually cause problems for dialects being portable (if we ever get that far with things).
Perhaps we need a "pre-prelude" or "minimal prelude" or something that's defined, and that a typical prelude or dialect can inherit? Or the dialect can be in the preprelude dialect?? (so any preprelude things aren't necessarily available down unless re-exported)

In minigrace, the identifierresloution pass assumes that there is a builtin scope that surrounds the prelude, but the code generators don't implement that. Hence, outer.outer at the top level is treated as legal, but crashes. I want to know the right way to fix this!

make "outer" work like "self" and the problem goes away.

James

[apblack]

I thought that this was an implementation detail, but it "shows through". It's exactly because outer is like self, and refers to a specific object, that it's visible.

I'm not really concerned whether for(_)do(_) is in the prelude or built-in — we can say it's in the prelude and fake it, if we want. But some things in the prelude are required to make the compiler work. For example, the checks on uninitialized variables, or on arguments having the wrong type, raise exceptions that need to be defined somewhere. These exceptions are part of the language: the same exceptions need to be raised regardless of which prelude the program is using. Other examples are the operations on types (like &), and indeed the constants true and false and the type Boolean. So it seems to me that there are, semantically, some things that are "built in".

I can fix the current inconsistency in minigrace in one of two ways. The purpose for posting this issue is to help me make the right choice, so that I can do it once rather than do it over.

[kjx]

how about there is another prelude dialect, coreGrace, that defines the intrinsics. the standardGrace prelude is in the coreGrace dialect.

This is different to the intrinsics being an additional layer surrounding everything, because this way the actual dialect mediates programs access to the intrinsics.

[apblack]

I think I agree with that proposal. If I understand it, there is a module called intrinsic (or primitive, or builtin), which defines "certain things". standardGrace imports intrinsic, and then re-exports "those things". Other dialects can import and re-export standardGrace, or intrinsic, or selective parts of either.

For any program (which must be written in a dialect), there is nothing outside its dialect. This is true even for standardGrace (which is written in dialect none).

If we agree on this, then all that remains is:

• To pick a name — intrinsic, primitive, and builtin all sound OK to me.
• To decide what's in it. true and false, for example, could be defs in intrinsic, or they could be a fundamental part of the language, like self. if(_)then(_)else(_) and while(_)do(_) should probably be in intrinsic.

The discussion of the second bullet should probably become a separate issue.

[KimBruce]

So, outer at the top level accesses the dialect (including intrinsic), while outer.outer is an error.

That seems fine to me.

On Oct 14, 2016, at 8:18 AM, Andrew Black notifications@github.com wrote:

I think I agree with that proposal. If I understand it, there is a module called intrinsic (or primitive, or builtin) which defines "certain things". standardGrace imports intrinsic, and then re-exports "those things". Other dialects can import and re-export standardGrace, or intrinsic, or selective parts of either.

For any program (which must be written in a dialect), there is nothing outside its dialect. This is true even for standardGrace (which is written in dialect none).

If we agree on this, then all that remains is:

To pick a name — intrinsic, primitive, and builtin all sound OK to me. To decide what's in it. true and false, for example, could be defs in intrinsic, or they could be a fundamental part of the language, like self. if()then()else() and while()do(_) should probably be in intrinsic. The discussion of the second bullet should probably become a separate issue.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/117#issuecomment-253831871, or mute the thread https://github.com/notifications/unsubscribe-auth/ABuh-uNdcBmDafl94LhfDX65hIhoCGudks5qz51bgaJpZM4KTx1Q.

[kjx]

I'm not sure it was a proposal, but it seems to make sense

[apblack]

I quite like intrinsic

[apblack]

I would like to implement this in minigrace as soon as I'm free of the C code generator.