One of my goals for GameLisp is to allow the programmer to sacrifice performance in exchange for extreme customisation. For example, it should eventually be possible for a custom iterator library to redefine functions like iter, iter-next! and iter-finished?.
Today, GameLisp's parser and printer are conspicuously non-customisable. They support a handful of primitive types, and nothing else.
This makes user-defined obj and rdata types less powerful than they ought to be. Fundamental types like BigInt and Point can't be serialized to a file, read in from a file, quoted, written as a self-evaluating literal (like #((a b)) for tables), or used as a macro's argument or return value.
The most general solution would be to make the parser fully customisable. This would enable the programmer to create their own literal syntax for each type, e.g. 0n1234 for a BigInt.
A simpler solution would be to provide function-invocation syntax for the parser. The text #(Point 0 0) would cause the parser to invoke the parser function which has been registered to the symbol Point, interleaving its return value into the parsed output.
Both of those options would be inelegant in their own way, so the third option would be to leave this issue as WONTFIX.
One of my goals for GameLisp is to allow the programmer to sacrifice performance in exchange for extreme customisation. For example, it should eventually be possible for a custom iterator library to redefine functions like
iter,iter-next!anditer-finished?.Today, GameLisp's parser and printer are conspicuously non-customisable. They support a handful of primitive types, and nothing else.
This makes user-defined
objandrdatatypes less powerful than they ought to be. Fundamental types likeBigIntandPointcan't be serialized to a file, read in from a file, quoted, written as a self-evaluating literal (like#((a b))for tables), or used as a macro's argument or return value.The most general solution would be to make the parser fully customisable. This would enable the programmer to create their own literal syntax for each type, e.g.
0n1234for aBigInt.A simpler solution would be to provide function-invocation syntax for the parser. The text
#(Point 0 0)would cause the parser to invoke the parser function which has been registered to the symbolPoint, interleaving its return value into the parsed output.Both of those options would be inelegant in their own way, so the third option would be to leave this issue as WONTFIX.