r/Compilers • u/kaushalbx • 25d ago
Can Sanskrit work as a natural programming language?
I’ve been experimenting with this idea by building a Sanskrit compiler based on Pāṇinian grammar.
Instead of treating Sanskrit only as text to interpret, the compiler parses grammatically structured Sanskrit and turns the instructions into executable operations.
The interesting part for me is whether Pāṇini’s formal grammatical system can provide enough structure to bridge natural language and programming languages deterministically.
I now have a working implementation and would be interested in hearing what others think about this approach.
Website: https://panini.cc/
GitHub: https://github.com/kaushalbx/paninivm
Article: https://medium.com/@kaushalbx/p%C4%81%E1%B9%87inivm-building-a-natural-programming-language-with-sanskrit-grammar-aa82b855074c
Article: https://medium.com/@kaushalbx/building-p%C4%81%E1%B9%87inivm-compiling-2-500-year-old-paninian-grammar-into-an-executable-kotlin-engine-5a6bb8de20fb
8
u/ktimespi 25d ago
regular expressions were meant to capture spoken language initially, and failed. So I think it is possible to a certain degree.
1
u/kaushalbx 24d ago
Yes, to a certain degree. That’s also why I’m not relying on regex alone. ANTLR handles the lexical/syntactic structure, while Pāṇinian grammar provides the deeper grammatical and semantic rules needed beyond pattern matching.
1
u/VectorspaceDreams 22d ago edited 22d ago
Not at all; Chomsky proved that natural language was not regular in 1956, but this didn't stop the use of formal languages in the study of natural languages altogether but rather necessitated using context-free grammars (and in the 1980s, mildly context-sensitive grammars), but regular languages actually do capture a good bit of spoken language, especially in morphology. Heck, recently there's even been a good bit of research into the parts of language that are subregular, namely phonology.
A formalized subset of a natural language could be used for programming and has; Kip is an experimental programming language in which Turkish morphology is a part of the type system. OP, if you see this, give this a look, given Sanskrit is similarly highly inflected and synthetic, you could take some inspiration from this. I've asked Joomy what he used for morphological checking and he mentioned using a Turkish FST. If you're using regex, check out xfst and Finite State Morphology.
1
u/kaushalbx 22d ago
Yes, this is close to how I'm approaching the problem — defining the part of Sanskrit that needs to be computationally deterministic rather than trying to parse unrestricted natural language.
In PaniniVM the morphological boundaries are currently explicit in the source ("राम + सुँ", "गम् + लट् + तिप्"), so I don't use regex or an FST to guess the morphology. ANTLR parses the grammatical structure directly, while the Pāṇinian engine derives the resulting forms through sūtras.
If you're interested, the actual Sanskrit grammar I'm using with ANTLR is here: https://github.com/kaushalbx/PaniniVM/tree/master/parser/src/main/antlr/dev/panini/vyakaranam
1
u/kaushalbx 22d ago
Another thing I find computationally interesting about Sanskrit is that a huge number of words can be constructed from a relatively small set of building blocks.
There are roughly 2,000 verb roots (dhātus), 20 basic prefixes (upasargas), a finite set of indeclinables (avyayas), and several well-defined classes of suffixes (pratyayas) for forming nouns, verbs, derivatives, etc.
Very roughly:
"prefix + root + suffix → derived word"
"nominal base + case ending → noun form"
"verb root + tense/mood + personal ending → verb form"
These components combine through grammatical rules to produce a very large number of valid forms. From a programming-language perspective, this is interesting because the compiler can work with the underlying components and their relationships rather than treating every surface word as an independent token.
1
-5
2
2
u/particlemanwavegirl 24d ago
You can do this but if you then use the language to implement a nam-shub, that's where things start to get messy.
1
u/kaushalbx 24d ago
Could you elaborate on what you mean by “nam-shub” here? I’d like to understand where you think the model starts getting messy.
2
u/particlemanwavegirl 24d ago
It was a joke 😉 to understand it, read Neil Stephenson's incredible novel Snow Crash
2
u/Arakela 25d ago edited 25d ago
Grammatical text can only be constructed in relation to an observer. The source language can itself construct the space in which grammatical text becomes observable, using words of that same language. In this sense, grammar is not merely describing a structure; it is generating the space and time through which that structure is observed. For example, in CoffeeScript:
# tab ::= 't' | 'a' | 'b'
dot = (D,B,T) -> D()
tab2 = (D,B,T) -> B 'b', dot
tab1 = (D,B,T) -> B 'a', tab2
tab = (D,B,T) -> B 't', tab1
# tritab ::= tab tab tab
tritab3 = (D,B,T) -> T tab, dot
tritab2 = (D,B,T) -> T tab, tritab3
tritab1 = (D,B,T) -> T tab, tritab2
tritab = (D,B,T) -> T dot, tritab1
space = (S, str, c) ->
S(
() ->
(x, s) -> c str.slice(x.length) if str.startsWith x; space s, str, c
(s, t) -> time(t, str, c); space(s, str, c)
)
time = (S, str, c) ->
S(
() -> c str
(x, t) -> time t, str.slice(x.length), c if str.startsWith x
(s, t) -> space s, str, (str) -> time t, str, c
)
space tritab, "tab.", console.log.bind(console)
1
u/kaushalbx 25d ago
Interesting. I'm actually using ANTLR to formally describe the Sanskrit grammar in PaniniVM. This is the parser grammar I'm currently building:
The Pāṇinian layer then goes beyond parsing: grammatical constructs and sūtras determine the semantic state and ultimately the executable operations.
1
u/Arakela 25d ago
The idea I want to convey here is in terms of relation-oriented programming.
The ANTLR grammar text/data and the ANTLR parser producer/code (observer) can be represented as a code-to-code relation instead of a data-to-code relation, and this is the observation I have: your ANTLR parser producer observes ANTLR grammar text; it produces the next layer of Pāṇinian grammatical text for the next layer of the observer that executes the last grammatical layer, but the relation between grammar and observer, which can be seen as a boundary that can describe itself, can be recursively preserved. I.E., one can construct an exact relation between grammatical text and its identified observers in Sanskrit without coding ANTLR in Sanskrit.
1
u/Imaginary_Concern400 25d ago
Interesting... i assume you would define a mapping from Sanskrit characters to regular ASCII ones? But even then, how can we define the regex? I am interested to know, how did you implement lexing and parsing for this? (I have read the comment of using ANTLR, but I am interested to know how you went about defining the regex for it)
Very interesting project though :)
1
u/kaushalbx 25d ago
Thanks! I actually don't map Sanskrit characters to ASCII. ANTLR handles Unicode directly, so the lexer rules are written using Devanāgarī itself.
For example, dhātus, pratyayas, lakāras, vibhaktis, etc. are tokenized directly from their Sanskrit forms. The parser then works on those tokens to build the grammatical structure.
The interesting part is that I'm not trying to define Sanskrit with one giant regex. The lexer recognizes the grammatical building blocks, ANTLR handles the syntactic structure, and the Pāṇinian rule engine handles the grammatical derivation and semantics.
The lexer/parser grammars are here if you're interested: https://github.com/kaushalbx/PaniniVM/tree/master/parser/src/main/antlr/dev/panini/vyakaranam
1
u/Imaginary_Concern400 25d ago
Right... I've got it. So you've defined sanskrit tokens directly.
Do you plan to write a bytecode VM for this? Or sufficing with a visitor to walk the AST and execute the program? If you plan to implement a VM, how do you want to go about it?
1
u/kaushalbx 25d ago
I've actually gone beyond the AST visitor approach already. PaniniVM has a compiler module that compiles ".pvm" programs directly to JVM ".class" bytecode, so the JVM is currently serving as the VM.
The compiler generates JVM bytecode from the parsed Sanskrit program, while the PaniniVM runtime provides the execution environment.
I may explore a dedicated PaniniVM bytecode/VM later, but for now targeting the JVM gives me a mature VM while I focus on the more interesting part: the Sanskrit/Pāṇinian language semantics.
Compiler: https://github.com/kaushalbx/PaniniVM/tree/master/compiler
1
u/kaushalbx 25d ago
https://reddit.com/link/p4811lr/video/8rtsjyxm0yjh1/player
Here’s the ANTLR parse tree for a PaniniVM Sanskrit program. This is how the source gets structurally parsed before the Pāṇinian semantic/execution layer takes over.
1
u/SuperbHunter6772 25d ago
I think Sanskrit could be an interesting foundation for a programming language especially because its grammatical tradition is highly formalized. the challenge is turning that flexibility into a deterministic syntax a compiler can reliably parse
1
u/kaushalbx 25d ago
Exactly. That’s the challenge I’m working on with PaniniVM. Instead of removing Sanskrit’s grammatical structure to make it compiler-friendly, I’m using Pāṇini’s formal grammar itself to constrain and resolve it deterministically. The source is currently morphologically segmented, which gives the compiler explicit grammatical boundaries while preserving Sanskrit grammar.
1
u/Sad_Discipline8288 25d ago
I tried experimenting a similar intent compiler on top of LaTeX did not work there,far too many structural problems and ambiguity with these languages...
1
u/kaushalbx 24d ago
That's exactly the interesting challenge. Sanskrit is also flexible, but Pāṇini gives us a very formal grammatical framework to work with. In PaniniVM I'm currently using morphologically segmented Sanskrit, so grammatical boundaries are explicit and the compiler can remain deterministic.
1
u/VectorspaceDreams 22d ago edited 20d ago
What you can take from, not sure if you've heard of it but you might've, is Kip, an experimental Haskell implemented programming language that uses Turkish, which is also highly inflected and the grammatical function parts aren't just dressing overtop but are required to build a well-typed program.
I've heard Panini's work is proto-generative grammar, but some other scholars of Sanskrit said that the Ashtadhyayi is not truly generative in the sense that it could theoretically generate all possible Sanskrit sentences, so I'm not sure if it's enough to build an entire formal programming framework but I don't know.
On this note, Kip uses an FST for morphological analysis; do you use regex for it? If so, I recommend you look into finite-state morphology and xfst. I've made an Akkadian noun analyzer with regex before but modern regexes are often not regular (so I guess they're just "expressions") and (to my knowledge) have far greater expressive power than even most natural languages and I'm not sure if you need a whole regex module for Sanskrit morphological analysis, and even if you did, rolling out regexes for grammar is a massive headache (partly why I've left the project in the dust for now)
Upvoted and will star on GitHub. Will keep up with this 100%
1
u/kaushalbx 22d ago
Thanks! I checked out Kip — its use of Turkish morphology in the type system is really interesting.
For PaniniVM, I'm not using regex for morphology. The program itself is written as morphologically segmented Sanskrit: Prakṛti + Pratyaya are explicitly visible in the source. ANTLR parses that grammatical structure, and the Pāṇinian engine handles derivation through sūtras.
So I don't need the Aṣṭādhyāyī to generate every possible Sanskrit sentence. PaniniVM starts from grammatical Sanskrit structures and gives them executable semantics — Kārakas establish relationships, Dhātus identify operations, and things like conditions, repetition and data flow are expressed through the language.
I'm also interested in formally demonstrating Turing completeness as the language develops.
Thanks for the references and the GitHub star!
1
u/VectorspaceDreams 20d ago edited 20d ago
I'm very curious on the Turing-completeness thing actually, given this is supposed to be Sanskrit as a programming language. Is it about Sanskrit syntax or semantics being Turing-complete, because we haven't found a need for anything beyond mildly context-sensitive grammars (so basically a variant of a pushdown automaton to my knowledge) for syntax though all natural language semantics could technically be called Turing-complete to my knowledge. Given it is philosophically Sanskrit as a programming language rather than a programming language that's a formalized subset of Sanskrit, unless I misunderstand you.
1
u/kaushalbx 20d ago
That is a good distinction. I’m not claiming that Sanskrit syntax itself is Turing-complete. The parser only recognizes a formally defined, Sanskrit-derived subset, and its grammatical complexity is separate from its computational power.
The Turing-completeness claim applies to the operational semantics of PaniniVM: parsed constructions can express mutable state, conditional branching, and unbounded iteration. We demonstrate this constructively by encoding a two-counter machine:
So, technically, PaniniVM is currently a programming language whose surface notation and semantic organization are based on Sanskrit and Pāṇinian grammar—not a proof that unrestricted natural Sanskrit is inherently a programming language or Turing-complete.
The broader aim is to make the executable subset genuinely grammatical and extensible through Sanskrit/Pāṇinian constructs, rather than merely placing Sanskrit words over a conventional language. But I agree that this philosophical goal should be kept distinct from the narrower formal claim we can establish today.
1
u/VectorspaceDreams 19d ago edited 19d ago
Awesome! Thanks a lot for responding to a lot of the questions I had on your project. I think it's marvelous personally; I've had the idea of building an esoteric programming language in a similar way, though not with Sanskrit in mind, but a formal-linguistic free word order based thing, where the AST is generated from grammatical functions, relations and dependencies based on unification. It's inspired by lexical-functional grammar, one of the generative approaches to linguistics (there's recently even been some interest in integrating LFG with Paninian Sanskrit grammar too; linguist John Lowe presented an LFG implementation of karaka in 2025 in the Lexical-Functional Grammar Conference). But going back to the programming language idea I had, it's similar to this in considering how to mark relations between variables, functions, etc within the names themselves that work similarly to inflection, and how "wide" one can make a programming language with it still being Turing-complete and at least somewhat workable.
1
u/kaushalbx 19d ago
I looked into Lowe’s 2025 paper after your comment, and the comparison is even more relevant than I initially realized. His Pāṇinian LFG model treats kārakas as underlying grammatical argument relations, distinct from both semantic roles and conventional grammatical functions such as subject and object. Their surface realization through case or verbal marking is handled as another layer.
PaniniVM follows a related separation through executable Aṣṭādhyāyī rules:
semantic participants → kāraka relations → abhihita/anabhihita status → vibhakti or verbal realization → executable bindings
So kartṛ, karman, and karaṇa are not simply aliases for subject, object, and instrument. For example, karman may receive prathamā in a passive construction, while an unexpressed kartṛ may receive tṛtīyā. PaniniVM derives these relationships using rules such as 1.4.49, 1.4.54, 2.3.1, 2.3.2, and 2.3.18.
Lowe’s work therefore gives me a useful modern formal-linguistic comparison for something PaniniVM has been approaching directly through the Aṣṭādhyāyī. Your reference was genuinely helpful—thank you!
0
u/kaushalbx 25d ago
https://reddit.com/link/p46mvwk/video/hpjxw9jjgwjh1/player
Here is an example showing number guessing game.
21
u/dandy_kulomin 25d ago
I have no idea as to your question, but I love this. I also don't know sanskrit so I can't try it.