Seeking APi advice on vidyut-prakriya

[Arun Prasad]

This file defines the main API for vidyut-prakriya. As the program starts to take its final shape, I would like advice on how to make this API more elegant.

Some issues I want to additionally support:

- नामधातु arguments for पुत्रीयति, etc.

- being able to derive subantas with a text string, a krdanta, a taddhitanta, or a samasa

- other options for making these methods more user-friendly

Potentially crazy ideas:

- a single derive method for all possible derivations? Possibly too flexible for most use cases.

[Shreevatsa R]

Could you say more about the expected users/usage of this API? Is it the one here: https://github.com/ambuda-org/vidyut/blob/main/vidyut-prakriya/README.md#usage ?

let a = Ashtadhyayi::new();

let dhatu = Dhatu::new("BU", Gana::Bhvadi);
let args = TinantaArgs::builder()
    .lakara(Lakara::Lat)
    .prayoga(Prayoga::Kartari)
    .purusha(Purusha::Prathama)
    .vacana(Vacana::Eka)
    .build().unwrap();

let prakriyas = a.derive_tinantas(&dhatu, &args);

--
You received this message because you are subscribed to the Google Groups "ambuda-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ambuda-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ambuda-discuss/88bd21dc-b777-4221-ba9d-0a9f6ad0c158n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arun Prasad]

Thanks for the reply.

Yes, that snippet is an example of using the derive_tinantas method, and likewise there are currently derive_subantas, derive_krdantas, derive_taddhitantas, and derive_vakyas methods. I am also considering a derive_samasas method, a derive_dhatus method, and a derive_stryantas method for स्त्री-pratyayas.

Audience: I expect that the users of this API will be power users who are familiar with Paninian grammar. I likewise foresee most people who use this package using it through the Python API, which for ease of maintenance will broadly mirror the Rust one but with some tweaks to be more Pythonic.

Goal for this project: The primary goal is to generate an exhaustive Sanskrit word list by following the rules of the Ashtadhyayi, etc. An important second goal is to have a complete reference implementation of the Ashtadhyayi, (I use the phrase "reference implementation" and avoid the word "simulation" because a simulation implies some explicit model of how to resolve conflicts between rules, which this project does not have.)

Goal for the API: My goal is to make the API as complex as it needs to be for the problem domain (i.e. the Ashtadhyayi) but avoid complexity from the language, clumsy API design, etc.

Motivating example: I'll focus on derive_tinantas. Here are properties I like:

- Has clear constraints based on Rust's enum types

- Easy to create a new Ashtadhyayi instance, which can model which rules apply, how to interpret certain rules, etc.

- Easy to create a dhatu. SLP1 is not ideal, but supporting other encodings would require transliterator support, which feels out of scope for this library.

Here are properties I don't like:

- Not obvious how to create a नामधातु. More generally, some methods could conceivably accept a bare pratipadika, a krdanta, a taddhitanta, a subanta, or perhaps even a verb. Rust's impl trait arguments might be able to support this, but it needs some more thought.

- Not obvious where to specify upasargas and other prefixes. Right now these are defined on Dhatu, but is that a natural place? Perhaps these should be a third argument -- but then that's clumsy if the user doesn't want to specify any prefixes. So perhaps prefixes should be on TinantaArgs -- but if so, perhaps dhatu should also be defined as part of TinantaArgs?

One idea I like, that I think you mentioned in a past conversation, is to allow TinantaArgs to have unspecified fields as a "generate everything" option. That is, if a user doesn't pass an explicit lakara, we should generate all lakaras that fit the constraints given. I think this is a great way to make the API more user friendly without sacrificing its precision.

Arun

[Arun Prasad]

The API ended up in a good place. See:

- https://github.com/ambuda-org/vidyut/blob/main/vidyut-prakriya/src/args.rs

- https://github.com/ambuda-org/vidyut/blob/main/vidyut-prakriya/ARCHITECTURE.md

Here is a sample of the major structs of interest. Together, they let us use the type system to recursive model a well-formed Paninian derivation. We still have multiple derivation functions like derive_krdantas, derive_tinantas, etc. But if we decide to use it in the future, we can have a single derive method that accepts any of the structs below.

#[derive(Clone, Debug, Eq, Hash, PartialEq)]
pub enum Pada {
    /// A nominal word or an indeclinable.
    Subanta(Subanta),
    /// A verb.
    Tinanta(Tinanta),
    /// A "chunk of text" without any specific morphology. This is a temporary variant that we hope
    /// to clean up later.
    Dummy(String),
    /// A dummy variant that we hope to clean up later.
    Nipata(String),
}

#[derive(Clone, Debug, Eq, Hash, PartialEq)]
pub struct Subanta {
    pratipadika: Pratipadika,
    linga: Linga,
    vibhakti: Vibhakti,
    vacana: Vacana,
    is_avyaya: bool,
}

#[derive(Clone, Debug, Eq, Hash, PartialEq)]
pub struct Tinanta {
    dhatu: Dhatu,
    prayoga: Prayoga,
    lakara: Lakara,
    purusha: Purusha,
    vacana: Vacana,
    pada: Option<DhatuPada>,
}

#[derive(Clone, Debug, Hash, Eq, PartialEq)]
pub enum Dhatu {
    /// Indicates a muladhAtu from the Dhatupatha.
    Mula(Muladhatu),
    /// Indicates a nAma-dhAtu created with a sanAdi-pratyaya.
    Nama(Namadhatu),
}

pub enum Pratipadika {
    /// A simple string that receives the pratipadika-samjna by rule 1.2.45.
    Basic(BasicPratipadika),
    /// A krdanta.
    Krdanta(Box<Krdanta>),
    /// A taddhitanta.
    Taddhitanta(Box<Taddhitanta>),
    /// A samasa.
    Samasa(Box<Samasa>),
}