Documentation ¶
Index ¶
- func Compile(filename string, oLevel ...uint8) (bytecode []byte, err error)
- func Deserialise(data []byte) (deserialised, error)
- func MakeFn(name string, fn func(args Args) (r Rets, err error)) [2]any
- func ToString(a any) string
- type Args
- func (a *Args) CheckNextArg()
- func (a *Args) GetAny(optV ...any) (arg any)
- func (a *Args) GetBool(optV ...bool) bool
- func (a *Args) GetBuffer(optV ...*Buffer) *Buffer
- func (a *Args) GetCoroutine(optV ...*Coroutine) *Coroutine
- func (a *Args) GetFunction(optV ...Function) Function
- func (a *Args) GetNumber(optV ...float64) float64
- func (a *Args) GetString(optV ...string) string
- func (a *Args) GetTable(optV ...*Table) *Table
- func (a *Args) GetVector(optV ...Vector) Vector
- type Buffer
- type Coroutine
- type Function
- type Rets
- type Status
- type Table
- func (t *Table) ForceSet(k, v any)
- func (t *Table) Get(k any) any
- func (t *Table) GetHash(k any) any
- func (t *Table) Iter() iter.Seq2[any, any]
- func (t *Table) Len() int
- func (t *Table) Set(k, v any) error
- func (t *Table) SetArray(i int, v any)
- func (t *Table) SetHash(k, v any)
- func (t *Table) String() (s string)
- type Vector
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Deserialise ¶
Types ¶
type Args ¶
func (*Args) CheckNextArg ¶
func (a *Args) CheckNextArg()
func (*Args) GetCoroutine ¶
func (*Args) GetFunction ¶
type Status ¶
type Status uint8
Functions and Tables are used as pointees normally, as they need to be hashed
type Table ¶
Q why are tables like this
A:
1: the reference implementation of tables is too complex: rehashing and resizing is a pain but not too bad, array boundaries are worse and I don't want 1.5k lines of code just for that, and Go does a resizing-like thing automatically with slices anyway
2: the way nodes are implemented works well in C++ and not in Go (plus I don't know if it's actually O(1) for node lookups??)
3: rehashing etc is slower than just using a slice... somehow. most of this program is between 10-20x slower than the reference implementation, but the tables (which were previously like 50x slower) are now only like 2-3x slower for large allocations (bench/largealloc.luau)
4: having an array part is actually nice for iteration and for large tables (as opposed to the lua4 way, where it's *just* a hash part), the way it's done here is simpler though we have to move stuff around and between the array and node parts more explicitly
5: very weird quirks arise from table length implementations etc. the nil stuff can easily be forgiven, it's the stuff with creating a table and getting a length afterwards (see tests/clear.luau) that is fucking devilish; this is one of the few parts that puts Luau, as the language at the top of my favourites list, in jeopardy
6: we don't actually break *that* much compatibility doing it this way, right??
7: if anyone tells you tables are simple THEY ARE LYING, CALL THEM OUT ON THEIR SHIT