<p>I'm designing a language that looks like this:</p>
<pre><code>to kiss (a: a animal) passionately:
    say &quot;you kiss&quot; a.

to kiss the frog passionately:
    say &quot;the frog turns into a princess&quot;.

the frog is a animal;
kiss the frog passionately.
</code></pre>
<p>This would print &quot;the frog turns into a princess&quot;. While both variations of the function are valid, the more specific one is preferred.</p>
<p>This language is intended to be beginner friendly and specifically used by children.</p>
<p>Note that functions can get a lot more complex with multiple arguments, consider this function:</p>
<pre><code>to attack (enemy: an enemy) with (weapon: a weapon):
    subtract the weapons damage from the enemys health // missspelling is intentional, language just inserts s for possessive with no regard for proper English grammar

the blue orc is a enemy
the blue orc has 5 health
the sword is a weapon
the sword has has 3 damage
attack the blue orc with the sword
say &quot;The blue orc now has &quot; the health of the blue orc &quot;health&quot;;
</code></pre>
<p>What techniques can I use to parse code like this? Seems a normal context-free grammar, or even a extended grammar wouldn't be able to handle this.</p>
<p>I want help specifically for parsing calls to user generated function, I can manage the normal statements myself, or will ask a separate question for them when I get stuck.</p>

<parsing><natural-language>
How to parse a language where functions are full sentences?
CC BY-SA 4.0
2023-05-20T19:47:45.793Z
The syntax feels a bit similar to [ORK](https://esolangs.org/wiki/ORK); maybe you could draw some inspiration from there.
DLosc
CC BY-SA 4.0
2023-05-20T19:48:53.720Z
You can see the JS source code of ORK here. It just parses everything with regex: http://www.formauri.es/personal/pgimeno/temp/esoteric/ork/OrkInterpreter.js
naffetS
CC BY-SA 4.0
2023-05-20T20:26:52.923Z
Give ChatGPT instructions and feed the source code into it :P
naffetS
CC BY-SA 4.0
2023-05-20T21:08:55.700Z
In the title, can you please disambiguate "sentences"? "english sentences"? "human language sentences"?
starball
CC BY-SA 4.0
2023-05-21T05:26:46.927Z
@starball the main point is that they are multiple words, they are not really english sentences since they follow a strictly defined structure that happens to look like english
mousetail 'he-him'
CC BY-SA 4.0
2023-05-21T09:04:07.563Z
@naffetS ChatGPT is factually inaccurate too often to be trusted.
The Empty String Photographer
CC BY-SA 4.0
2023-05-21T11:15:36.873Z
Kissing frogs is disgusting!
The Empty String Photographer
CC BY-SA 4.0
2023-05-21T14:53:30.740Z
This also looks like [Mizar](http://mizar.uwb.edu.pl/).
Alex Nelson
<p>In a broad sense, these are <em>mixfix</em> function names: multiple-word names with arguments interspersed. They are not very common, but found most: famously in: Smalltalk, and also in Grace, where I got my experience with them. For context, here is a definition of your more complex example in Grace:</p>
<pre class="lang-none prettyprint-override"><code>method attack (enemy: Enemy) with (weapon: Weapon) {
    subtract(weapon.damage) from (enemy.health)
}
</code></pre>
<p>That language requires parentheses around non-literal arguments, but this isn't strictly required to parse as long as you can tell where the argument expression stops. In this example you shouldn't have any trouble with that, but we'll come back to <code>blue orc</code> later.</p>
<p>There are two parsers I'll discuss: a hand-rolled recursive descent parser I wrote, and <a href="https://github.com/kjx/combinators/blob/master/grammar.grace" rel="noreferrer">a parser-combinator one</a> by someone else. There was also a <a href="https://repository.tudelft.nl/islandora/object/uuid%3A76ab40b5-ccdb-4db1-95ef-db71c01e0c7f" rel="noreferrer">Spoofax implementation</a> that used an SDF3 grammar, but I can't speak to it. All of them should accept the same syntax as far as this goes, so methodology is not vastly important.</p>
<p>The <a href="https://github.com/mwh/kernan/blob/master/GraceLanguage/Parsing/Parser.cs#L1797" rel="noreferrer">parser code</a> for something like that expression:</p>
<ol>
<li>Expects to have seen an identifier token to the left.</li>
<li>Parses the arguments for this part: either a self-delimiting literal (<code>1</code>, <code>&quot;string&quot;</code>) or a parenthesised list. This is where things get slightly more complex for you.</li>
<li>Looks ahead for a further identifier token immediately following the arguments: if so, repeat, accumulating all name parts and arguments.</li>
<li>Return the collected list of (name, argument list) pairs, and collate all the name parts together to identify the method in use in the same way that the declaration did.</li>
</ol>
<p>The combinator version just does the same thing declaratively: <a href="https://github.com/kjx/combinators/blob/master/grammar.grace#L48" rel="noreferrer"><code>firstArgumentHeader ~ repsep(argumentHeader,opt(ws))</code></a>, which shouldn't be a problem in most kinds of grammar. In both cases this is an eager consumption because two terms in a row are not legal, which seems to be the case in your version as well.</p>
<hr />
<p>You have two complications, both in the argument lists.
One is in <code>kiss the frog passionately</code>, in that there's no argument list after <code>passionately</code>, which this algorithm would reject. This shouldn't be any trouble to fix in itself.</p>
<p>The other is in <code>attack the blue orc with the sword</code>. Presumably <code>the</code> is treated as a keyword and handled, but <code>blue orc</code> is still two words and we need to know to take them together and not expect a function <code>attack...orc...sword</code>. There are a few possible cases here, depending on what else the language does:</p>
<ul>
<li>Most straightforwardly, we just know which identifiers have been created already and can peek ahead to take a full identifier if it's present. This can also operate for functions like the <code>kiss the frog passionately</code> overload.</li>
<li>It may be that every argument will always start with <code>the</code>, and so we just continue until the word that precedes that. This also falls over on the <code>passionately</code> case, but otherwise aligns with the Smalltalk <code>:</code>. The declaration of <code>kiss the frog passionately</code> would also recognise a parameter slot in the middle in this case.</li>
<li>There may be a concept of adjectives as prefixes such that <code>blue</code> still requires a noun afterwards and is consumed as part of a single term.</li>
<li>More awkwardly, you can generate multiple candidate parses and reject those that don't pan out. From the examples so far, these should uniquely disambiguate once names in scope are known.</li>
</ul>
<p>I'm not sure which path will be right for this language, but it shouldn't present a major obstacle. It just needs to be dealt with somehow. The multi-word <em>possessives</em> should not be an issue, since you can tell that there is more to come, only multi-word heads of phrase.</p>
<p>The <code>kiss the frog passionately</code> overload of <code>kiss (animal) passionately</code> can be handled with multiple dispatch after parsing, and doesn't have to be addressed at this stage.</p>
<hr />
<p>There aren't any in your example, but I'll note that one place where a problem does arise (and why Grace ended up with the parentheses) is when a multi-part function call can be an <em>argument expression</em> to another multi-part function: something like <code>nearest...to</code> in <code>attack nearest enemy to me with the sword</code> is difficult to parse without further indications.</p>

CC BY-SA 4.0
2023-05-20T21:37:30.023Z
2023-05-21T21:37:58.277Z
2023-05-21T21:37:58.277Z
Michael Homer
# How to parse a language where functions are full sentences?
Posted by: username_0 on 2023-05-20
I'm designing a language that looks like this:
to kiss (a: a animal) passionately:
    say "you kiss" a.

to kiss the frog passionately:
    say "the frog turns into a princess".

the frog is a animal;
kiss the frog passionately.

This would print "the frog turns into a princess". While both variations of the function are valid, the more specific one is preferred.
This language is intended to be beginner friendly and specifically used by children.
Note that functions can get a lot more complex with multiple arguments, consider this function:
to attack (enemy: an enemy) with (weapon: a weapon):
    subtract the weapons damage from the enemys health // missspelling is intentional, language just inserts s for possessive with no regard for proper English grammar

the blue orc is a enemy
the blue orc has 5 health
the sword is a weapon
the sword has has 3 damage
attack the blue orc with the sword
say "The blue orc now has " the health of the blue orc "health";

What techniques can I use to parse code like this? Seems a normal context-free grammar, or even a extended grammar wouldn't be able to handle this.
I want help specifically for parsing calls to user generated function, I can manage the normal statements myself, or will ask a separate question for them when I get stuck.
**Tags:** parsing natural-language
> **Comments:**
> **username_1**: The syntax feels a bit similar to [ORK](https://esolangs.org/wiki/ORK); maybe you could draw some inspiration from there.  
> **username_2**: You can see the JS source code of ORK here. It just parses everything with regex: http://www.formauri.es/personal/pgimeno/temp/esoteric/ork/OrkInterpreter.js  
> **username_2**: Give ChatGPT instructions and feed the source code into it :P  
> **username_3**: In the title, can you please disambiguate "sentences"? "english sentences"? "human language sentences"?  
> **username_0**: @starball the main point is that they are multiple words, they are not really english sentences since they follow a strictly defined structure that happens to look like english  
> **username_4**: @naffetS ChatGPT is factually inaccurate too often to be trusted.  
> **username_4**: Kissing frogs is disgusting!  
> **username_5**: This also looks like [Mizar](http://mizar.uwb.edu.pl/).  
---
## 1 answers
### Answer by username_6 on 2023-05-20. Score: 9
In a broad sense, these are mixfix function names: multiple-word names with arguments interspersed. They are not very common, but found most: famously in: Smalltalk, and also in Grace, where I got my experience with them. For context, here is a definition of your more complex example in Grace:
method attack (enemy: Enemy) with (weapon: Weapon) {
    subtract(weapon.damage) from (enemy.health)
}

That language requires parentheses around non-literal arguments, but this isn't strictly required to parse as long as you can tell where the argument expression stops. In this example you shouldn't have any trouble with that, but we'll come back to blue orc later.
There are two parsers I'll discuss: a hand-rolled recursive descent parser I wrote, and a parser-combinator one by someone else. There was also a Spoofax implementation that used an SDF3 grammar, but I can't speak to it. All of them should accept the same syntax as far as this goes, so methodology is not vastly important.
The parser code for something like that expression:

Expects to have seen an identifier token to the left.
Parses the arguments for this part: either a self-delimiting literal (1, "string") or a parenthesised list. This is where things get slightly more complex for you.
Looks ahead for a further identifier token immediately following the arguments: if so, repeat, accumulating all name parts and arguments.
Return the collected list of (name, argument list) pairs, and collate all the name parts together to identify the method in use in the same way that the declaration did.

The combinator version just does the same thing declaratively: firstArgumentHeader ~ repsep(argumentHeader,opt(ws)), which shouldn't be a problem in most kinds of grammar. In both cases this is an eager consumption because two terms in a row are not legal, which seems to be the case in your version as well.

You have two complications, both in the argument lists.
One is in kiss the frog passionately, in that there's no argument list after passionately, which this algorithm would reject. This shouldn't be any trouble to fix in itself.
The other is in attack the blue orc with the sword. Presumably the is treated as a keyword and handled, but blue orc is still two words and we need to know to take them together and not expect a function attack...orc...sword. There are a few possible cases here, depending on what else the language does:

Most straightforwardly, we just know which identifiers have been created already and can peek ahead to take a full identifier if it's present. This can also operate for functions like the kiss the frog passionately overload.
It may be that every argument will always start with the, and so we just continue until the word that precedes that. This also falls over on the passionately case, but otherwise aligns with the Smalltalk :. The declaration of kiss the frog passionately would also recognise a parameter slot in the middle in this case.
There may be a concept of adjectives as prefixes such that blue still requires a noun afterwards and is consumed as part of a single term.
More awkwardly, you can generate multiple candidate parses and reject those that don't pan out. From the examples so far, these should uniquely disambiguate once names in scope are known.

I'm not sure which path will be right for this language, but it shouldn't present a major obstacle. It just needs to be dealt with somehow. The multi-word possessives should not be an issue, since you can tell that there is more to come, only multi-word heads of phrase.
The kiss the frog passionately overload of kiss (animal) passionately can be handled with multiple dispatch after parsing, and doesn't have to be addressed at this stage.

There aren't any in your example, but I'll note that one place where a problem does arise (and why Grace ended up with the parentheses) is when a multi-part function call can be an argument expression to another multi-part function: something like nearest...to in attack nearest enemy to me with the sword is difficult to parse without further indications.
---
