Skip to content

Latest commit

 

History

History
62 lines (46 loc) · 2.6 KB

README.md

File metadata and controls

62 lines (46 loc) · 2.6 KB

scrapiyard

Documentation files for EDOPro's Card Scripting API

This repository aims to provide a single comprehensive source of truth for EDOPro scripting documentation and type information, stored in a properly version-controlled interchange format that facilitates easier human contribution and tooling development.

Contribute

Currently, we're working on checking every doc, correcting and modernizing them as needed after they were imported from the old format. There are over 2000 entries to go through so any help would be appreciated.

See v1-nification to get started with contributing.


Format

Documentation entries are in yaml format, found under /api/, following the specifications detailed in /specs/.

The specs are meant to be highly specialized for the EDOPro scripting environment. It does NOT aim to be able to represent the lua language as a whole or a general-purpose lua environment.

Spec considerations take inspiration from the following projects:

Emergent Type System

Since the documentation spec needs to be able to represent types in some form, it naturally gives rise to a type system. This emergent type system is very limited by design, as it must be reasonably easy to read and write in yaml format first and foremost, and it needs only to specialize in type concepts relevant to EDOPro scripting. Namely:

  • function types, with support for function overloading
  • table types, with support for mapped types
  • subtyping, but all function types must be a subtype of function and all table types must be a subtype of table
  • union types

It does NOT aim to support more advanced type concepts such as, but not limited to:

  • generics
  • intersection types
  • literal types

Furthermore, every type must be documented as a separate entry even if they are only used once. Anonymous types are not supported to avoid arbitrary deep nesting and circular references in the yaml files. Union types are the only exception. They are represented by a list of type names (the union itself does not need to be named or have a separate doc entry).