dingo

# Dingo Language Patterns

## Overview

Dingo is a meta-language for Go that transpiles `.dingo` files to `.go` files, providing modern language features while maintaining 100% Go ecosystem compatibility.

**Repository:** https://github.com/MadAppGang/dingo

**When to use Dingo:**
- You want concise error handling with the `?` operator
- You need sum types (enums) and pattern matching
- You prefer functional patterns with lambdas
- You want `Option[T]` and `Result[T,E]` types
- You need safe navigation (`?.`) and null coalescing (`??`)

**Key Philosophy:**
Dingo makes common Go patterns more concise and safer without departing from Go idioms. The transpiled Go code is clean and idiomatic.

## Project Structure

```
project/
├── cmd/
│   └── api/
│       └── main.dingo         # Entry point
├── internal/
│   ├── handlers/              # HTTP handlers (.dingo files)
│   ├── services/              # Business logic
│   ├── repositories/          # Data access
│   └── models/                # Domain models
├── pkg/                       # Public packages
├── configs/                   # Configuration
├── go.mod                     # Go module file
├── go.sum                     # Go dependencies
└── .dingo/                    # Generated .go files (gitignored)
```

## Build & Development Workflow

### Commands

```bash
dingo build          # Transpile to Go and build binary
dingo run main.dingo # Transpile and run directly
dingo go             # Generate .go files only (for CI/CD)
dingo fmt            # Format Dingo files
```

### Development Cycle

1. **Write**: Edit `.dingo` files
2. **Transpile**: Run `dingo go` to generate `.go` files in `.dingo/`
3. **Type Check**: gopls works on generated `.go` files for IDE support
4. **Build**: `dingo build` or `go build` on generated files

### IDE Integration

gopls (Go language server) works on the generated `.go` files:
```bash
# After dingo go, gopls sees:
.dingo/
├── cmd/api/main.go
├── internal/handlers/user.go
└── internal/services/user.go
```

Configure your editor to watch `.dingo/` for Go analysis.

### CI/CD Pipeline

```yaml
# GitHub Actions example
steps:
  - name: Install Dingo
    run: go install github.com/MadAppGang/dingo/cmd/dingo@latest

  - name: Generate Go files
    run: dingo go

  - name: Build
    run: go build -o app ./.dingo/cmd/api

  - name: Test
    run: go test ./.dingo/...
```

### Transpilation Errors

Dingo reports errors with source locations in `.dingo` files:

```
error: mismatched types in match expression
  --> internal/handlers/user.dingo:42:5
   |
42 |     match status {
   |     ^^^^^ expected Status, found string
```

Fix errors in `.dingo` source, then re-run `dingo go`.

## Built-in Types

**Important:** `Option[T]`, `Result[T,E]`, `Some()`, `None()`, `Ok()`, `Err()` are **built-in Dingo syntax**, not Go imports. The transpiler generates all necessary type definitions.

```dingo
// These are built-in - no import needed
func findUser(id string) Option[User] {
    // ...
    return Some(user)  // Built-in function
    return None()      // Built-in function
}

func divide(a, b int) Result[int, string] {
    if b == 0 {
        return Err("division by zero")  // Built-in
    }
    return Ok(a / b)  // Built-in
}
```

Only import `dgo` if writing **pure Go code** that interoperates with Dingo-generated types.

## Error Propagation (? Operator)

The `?` operator provides concise error handling, similar to Rust.

### Basic Propagation

```dingo
// Before: verbose Go pattern
func loadUser(id string) (*User, error) {
    user, err := db.FindByID(id)
    if err != nil {
        return nil, err
    }
    return user, nil
}

// After: concise Dingo
func loadUser(id string) (*User, error) {
    user := db.FindByID(id)?
    return user, nil
}
```

### Error Context

Add context to propagated errors:

```dingo
func processOrder(id string) (*Order, error) {
    // Wrap error with message
    order := db.FindOrder(id) ? "failed to find order"

    // Validates and wraps
    validated := validateOrder(order) ? "order validation failed"

    // Process with full context
    result := processPayment(validated) ? "payment processing failed"

    return result, nil
}
```

### Error Transform

Transform errors with closures:

```dingo
func createUser(input CreateUserInput) (*User, error) {
    // Rust-style closure
    user := db.Create(input) ? |e| fmt.Errorf("db error: %w", e)

    // TypeScript-style arrow
    profile := createProfile(user.ID) ? e => AppError.Wrap(e, "profile creation")

    return user, nil
}
```

### Error Propagation in Lambdas

When using `?` inside lambda bodies, the error propagates to the enclosing function:

```dingo
func processAllUsers(ids []string) (*Summary, error) {
    // Error in lambda propagates to processAllUsers
    results := map(ids, |id| {
        user := db.FindUser(id)?  // Propagates to processAllUsers, not the lambda
        return transform(user)
    })

    return summarize(results), nil
}

// For lambdas that should handle errors internally:
func processAllUsersSafe(ids []string) []Result[User, error] {
    return map(ids, |id| {
        user, err := db.FindUser(id)
        if err != nil {
            return Err(err)
        }
        return Ok(user)
    })
}
```

**Important:** The `?` operator inside lambdas propagating to the enclosing function is **intentional Dingo design**. When the transpiler sees `?` inside a lambda body, it generates special code that propagates errors to the enclosing function rather than the lambda itself. This is the most common use case for error handling in functional chains. If you need the lambda to handle errors internally (e.g., to return `Result` types), use explicit Go-style error checking as shown in `processAllUsersSafe` above.

## Option[T] Type

Use `Option[T]` for optional values instead of nullable pointers.

### Basic Usage

```dingo
func findUser(id string) Option[User] {
    user, err := db.FindByID(id)
    if err != nil {
        re