Nailing down the core of the language

[orbitaldecay]

As I am documenting the core behavior of the language in the manual, I realize that it is tricky to distinguish between the behavior of the fngi language proper, and the built-in syn tokens.

I am writing all of this from the perspective of a person who is trying to understand the execution model of the fngi language (e.g. Jane programmer).

The built-in syn tokens provide many exceptions to the syntax and behavior of the core of the fngi language. Indeed, syn functions in general provide endless such exceptions. I think most (almost all) of the built-in syn tokens could be moved to an optional standard library without effecting the capability of the fngi language. To me, this means they are not really in the "core" of the language. For example, you can't move "(" in C to the standard library, but you can do this in the fngi language. This is actually really elegant and beautiful. I think the only built-in fngi actually needs is the ability to include a module. Neat! This has huge implications for standard library design.

But this raises some questions about documentation. What exactly is the behavior of the core of the fngi language, if we strip away all built-in syn tokens? The behavior of the core seems like a good place to start if one seeks to understand the behavior of the language.

From what I can gather, excluding exceptions created by syn tokens, the following things are true (see current iteration of manual for definitions of monospace terms):

1. Tokens are evaluated left to right, top to bottom.
2. After tokens are evaluated, they are executed. Execution is either immediate, or delayed. Delayed tokens are executed in the order in which they were evaluated.
3. Syn tokens are always executed immediately. Syn tokens have basically the ability to do anything (create, evaluate and execute other tokens in any order, immediately, or delayed, etc.).

Is this true of the core loop?

[vitiral]

I think you pretty much have it. The core fngi loop only compiles one of the five token types. Without syn functions, you could never define a function or enter a function body, so you wouldn't be able to compile normal functions, values or variables since you first need to allocate a codeBuf. You could also not enter immediate mode, since that is also a syn function. I think the only thing you could do is leave comments 😅

[orbitaldecay]

I think you pretty much have it. The core fngi loop only compiles one of the five token types. Without syn functions, you could never define a function or enter a function body, so you wouldn't be able to compile normal functions, values or variables since you first need to allocate a codeBuf. You could also not enter immediate mode, since that is also a syn function. I think the only thing you could do is leave comments 😅

Yeah, that's what I thought 😆 But, in theory you could move all that stuff to an external library and just have an "include" syn function that loaded it and made it available?

[vitiral]

Sure, assuming the library somehow loaded the symbols. In essence this is all that Kern_fns is 🙂