stepchowfun / typical Goto Github PK

First off, great framework! As someone who hasn't worked a lot with data interchange formats, I was surprised that the first formats I ran into didn't have both strict support for non-nullable types and ADTs.

Description
I'm trying to define a recursive type, but it looks like it's not supported.

[Error] Cycle detected: types.Foo → types.FooOrBar → types.Foo.

Schema:

struct Foo {
    a: String = 0
    b: FooOrBar = 1 
}

struct Bar {
    a: String = 0
}

choice FooOrBar {
    foo: Foo = 0
    bar: Bar = 1
}

I was hoping that making the field optional, or replacing a directly recursive field with a choice that allows the recursion to end would allow the codegen to succeed, but it looks like recursive types in any form will trigger the error.

Are there any thoughts / plans on supporting this? I could imagine having some ability to limit the depth, like Rust's ![recursion_limit = "512"].

This would have to result in a Box on the rust side: Playground

Typescript

Alternatives considered
The actual situation I'm working with is in modeling a type-check diagnostic result from typescript's compiler api. As a workaround, I've added another type which omits the recursive field, and will have to flatten out the data into a plain array

Typical

struct Diagnostic {
    source: String = 0
    information: [DiagnosticInformation] = 1
}

struct DiagnosticInformation {
    category: DiagnosticCategory = 0
    code: S64 = 1
    optional file: File = 2
    optional start: U64 = 3
    optional length: U64 = 4
    message: DiagnosticMessage = 5
}

choice DiagnosticCategory {
    warning = 0
    error = 1
    suggestion = 2
    message = 3
}

choice DiagnosticMessage {
    text: String = 0
    chain: DiagnosticMessageChain = 1
}

struct DiagnosticMessageChain {
    text: String = 0
    category: DiagnosticCategory = 1
    code: S64 = 2
    # Recursive in typescript's compiler API definition. Flatten out before sending
    optional next: [DiagnosticMessageChainFlat] = 3
}

struct DiagnosticMessageChainFlat {
    text: String = 0
    category: DiagnosticCategory = 1
    code: S64 = 2
}

Taken from typescript 4.7.4 source code

export interface Diagnostic extends DiagnosticRelatedInformation {
        /** May store more in future. For now, this will simply be `true` to indicate when a diagnostic is an unused-identifier diagnostic. */
        reportsUnnecessary?: {};
        reportsDeprecated?: {};
        source?: string;
        relatedInformation?: DiagnosticRelatedInformation[];
    }

 export interface DiagnosticRelatedInformation {
        category: DiagnosticCategory;
        code: number;
        file: SourceFile | undefined;
        start: number | undefined;
        length: number | undefined;
        messageText: string | DiagnosticMessageChain;
    }

 /**
     * A linked list of formatted diagnostic messages to be used as part of a multiline message.
     * It is built from the bottom up, leaving the head to be the "main" diagnostic.
     * While it seems that DiagnosticMessageChain is structurally similar to DiagnosticMessage,
     * the difference is that messages are all preformatted in DMC.
     */
    export interface DiagnosticMessageChain {
        messageText: string;
        category: DiagnosticCategory;
        code: number;
        next?: DiagnosticMessageChain[];
    }

Description
Seems like there's no built in Map type

Alternatives considered
I think this can be worked around by doing something like

struct MapEntry {
  key: String = 0
  value: String = 1
}

struct Map {
  values: MapEntry = 0
}

Additional context
Just curious if this is an intentional design decision to omit, or just something with a good enough workaround that there's no need to implement it.

Description
It would be nice to see an example types.t file for the exhaustive pattern matching typescript example in the documentation, if you have the time for it. I'm sure for many readers it is obvious from the documentation written so far how one would create a schema that would generate this code, but not for me, and I think the extra example case would help my understanding of the project a lot.

Thanks for considering it!

Description
Codegen for Java.

It'd have to make a top level class that holds static classes for the actual schemas (so Schemas.EmailRequestOut for example), unless the codegen emitted multiple files.

Additional context
I am happy to work on this if it will be considered.

I was wondering if typical is interest in adding a third top level type (in addition to struct and choice), rpc. That way one can model their APIs in typical along side their data models. For example:

struct User {
  id: String = 0
  username: String = 1
}

struct CreateUserInput {
  user: User = 0
}

choice CreateUserOutput {
  success = 0
  error: String = 1
}

rpc UserService {
  createUser(CreateUserInput): CreateUserOutput
}

I can imagine asymmetric also being useful for rpc as a way to deprecate API endpoints. Where the server must implement it, but the clients must handle the case where it is gone.

rpc UserService {
  # Deprecated: Use createUserV2 instead
  asymmetric createUser(CreateUserInput): CreateUserOutput
  createUserV2(CreateUserInputV2): CreateUserOutput
}

Or does RPC just open up a whole can of worms that typical doesn't want to deal with? My thinking is that Typical wouldn't handle the actual doing of the rpc, but the code generation would provide hooks for userland to fill in. That way the rpc could be through any user-defined protocol.