/
TODO
111 lines (82 loc) · 5.03 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
This is a sort of unordered roadmap for Pez. Pez is a side project of a side
project, so this isn't strict. I don't expect anyone is running Pez in
production anywhere, so usually the author throws features around with no regard
for the roadmap.
Incidentally, I have been running Pez for a number of programs for a couple of
years now. It is fairly stable, and there are no bugs for the use cases that I
run into, but there are relatively few eyes on the code, and I believe myself to
be the only heavy user. The activity on the repo may be low, but the good news
is that this is largely because Pez works well.
NOW (1.6.0 release)
* Use flags in the interpreter struct instead of #define's for features
to support or disallow. The basics have been set up, but are not
implemented.
* Restructure the dictionary, so that flags are no longer stored in the
first byte of the name field, and so that file:line are included in entries.
* Finalize the API for a Pez interpreter instantiated by another Pez
program, so that the above-mentioned jailing of sub-pez's makes sense.
* gsub
* Clean up command-line parsing!
* Fix up size limits on instantiation.
* Un-break BSD. This involves un-breaking TinyCC for BSD, or selectively
disabling FFI/JIT where TinyCC isn't found. This involves some autotools
headaches.
* Clean up FFI somewhat. The #defines that have lingered are causing
intermittent issues, but so far it seems this is only the case when the code
calling FFI-defined functions is buggy. The FFI also needs its own test
suite, so that the standard test suite can run without requiring FFI.
* Add some features to the FFI. Namely, some (at least rudimentary) support for
structs defined in C headers, and perhaps some riskier operations than are now
allowed. Using TinyCC for the FFI, access to struct members, macros, etc., is
fairly straightforward.
* Fix interrupts; currently the sighandler sets a flag and we just poll, so a
lengthy call continues before we actually handle the interrupt.
ONGOING
* Misc cleanup and simplification.
* Include more batteries. Flesh out the standard library. Have a look at Lua
for this. Sockets (but with a good API) are near the top of the list,
although there is a fairly complete SQLite3 implementation, and TokyoCabinet
would be nice to add. I've plans to fix and release the SDL FFI; Pez has
some potential (being both speedy and fun) for game development.
LATER
* Serialization of the dictionary/code/etc.
* I expect text to be easier than binary images.
* Also, do both if possible.
* Also, binary images are likely to be better supported by the OS than
by the language proper. For example, DragonFly's checkpt feature.
* Maybe get rid of the case-insensitivity and turn everything lower-case;
depends on how much of a pain that turns out to be. This is low-priority;
currently, the case-insensitivity hasn't caused any problems, but does incur a
minor speed hit for compilation (strcasecmp versus strcmp), and there are
personal aesthetic reasons.
* Maybe, to decrease the amount of pointer-chasing required, just store function
pointers (rather than dictword pointers) on the heap. This is actually no
less safe than the current approach, but does involve touching several parts
of the code. In particular (and among other things), direct access to curword
needs to be cut off, and replaced with a function. Compilation would take
another speed hit, but this would be more than offset by a decrease in memory
traffic when executing, which would speed things up dramatically.
* Bolt down the security model, and perhaps handle segfaults a bit more
gracefully.
* Tweak the I/O so that interpreter-generated messages can be sent through a
pipe or arbitrary FD (as opposed to talking to stderr, etc., directly), so
that the UI can be interacted with.
* Mailboxes for communicating between Pez instances, when a concurrency model
is implemented. I hesitate to use pthreads, but that may be the best option.
* Un-break HaikuOS. I want to use Pez there!
* Possibly add lambdas. They're not extremely useful in a Forth-like language,
but it would be simple to add. (A function with an empty name, address pushed
onto the stack when ';' is executed.)
* Determine if we can determine (using the public API) whether a pointer falls
within memory allocated by BoehmGC, so that pointer safety can be reintroduced
without limiting things to the heap.
* Compilation of Pez code to a executable or library. Getting linkable or
executable code written in Pez recently began to look like it might be easier
than it previously looked.
MUCH LATER
* Come up with a plan for handling strings differently, maybe. Pez is extra
slow for string-heavy code, due to the relentless copying (and BoehmGC's
zero'ing of memory). This may introduce too big a gap between Pez and the
underlying C runtime, so it may not be worth the effort. Pez isn't really
a string-heavy language, but a solution would be nice.
* Investigate a few key optimizations, to speed up the language overall.