blob: a9f311dc14c55a3402b6d8412a2b4aec51dbab96 (
plain) (
blame)
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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
* codegen for threadvars
* two issues for thread local heaps:
- must prevent to construct a data structure that contains memory
from different heaps: n.next = otherHeapPtr
* add --deadlock_prevention:on|off switch? timeout for locks?
* test the sort implementation again
High priority (version 0.9.0)
=============================
- iterators should not always be destructive!
- warning for implicit openArray -> varargs convention
- implement explicit varargs
- tests: run modules that contain "#RUN_ME", compile the other
modules; run the GC tests
- fix the streams implementation so that it uses methods
- fix overloading resolution
- wrong co-/contravariance
- make ^ available as operator
Bugs
----
- proc (x: int) is passable to proc (x: var int) !?
- the parser allows empty object case branches
- pegs: the anchor '^' does not work because many procs use a linear search
and matchLen()
- BUG: generic assign still buggy
- Optimization: If we use a temporary for the result anyway the code gen
should make use of this fact to generate better code...
- bug: invoking a generic iterator twice triggers a code gen bug
- sorting with leads to a strange memory corruption!
--> system.swap or genericAssign is broken! And indeed, if reference counts
are not modified and the GC is triggered in between a swap, bad things
may happen!
proc sort*[A](t: var TCountTable[A]) =
for i in 0 .. high(t.data)-1:
var maxIdx = i
for j in i+1 .. high(t.data):
if t.data[j].val == 3: echo "touched! ", t.data[j].key
if t.data[j].val > t.data[maxIdx].val: maxIdx = j
swap(t.data[maxIdx], t.data[i])
To implement
------------
* distinct types for array/seq indexes
* implement closures for the C code generator
* GC: marker procs for native Nimrod GC and Boehm GC
* built-in serialization
Low priority
------------
- implicit ref/ptr->var conversion; the compiler may store an object
implicitly on the heap for write barrier efficiency
- resizing of strings/sequences could take into account the memory that
is allocated
- typeAllowed() for parameters...
- find a way to reintroduce the cleanup() pass for C code generation: this
is hard because of partial evaluation --> symbol files will fix this as
a side effect
- floating point checks for EcmaScript
- prefer proc in current module over other procs with same overloading result?
- real types for template results
- generalized case statement (requires better transf)
- tlastmod returns wrong results on BSD (Linux, MacOS X: works)
- nested tuple unpacking
- better error messages for used keywords as identifiers
- case statement branches should support constant sets
- 'nimrod def': does not always work
- test branch coverage
- checked exceptions
- fix implicit generic routines
Library
-------
- specialized bit sets; specialized string sets
- locale support
- conversion between character sets
- bignums
- ftp (and other internet protocols)
- pdcurses bindings
- queues additional to streams: have two positions (read/write) instead of one
- for system:
proc `@` [T](a: openArray[T]): seq[T] =
newSeq(result, a.len)
for i in 0..a.len-1: result[i] = a[i]
--> ensure @[] calls the array version!
Version 2
---------
- language change: inheritance should only work with reference types, so that
the ``type`` field is not needed for objects! --> zero overhead aggregation
BETTER: ``is`` and safe object conversions only work with ref objects. Same
for multi methods.
- explicit nil types?
* nil seq[int]
* nil string
* nil ref int
* nil ptr THallo
* nil proc
- better for backwards compatibility: default nilable, but ``not nil``
notation:
type
PWindow = ref TWindow not nil
The problem with ``nil`` is that the language currently relies on it for
implicit initialization. Initialization is different from assignment. The
issues can "easily" dealt with by ensuring:
var x = myProc() # checks myProc() initializes every pointer explicitely
- the two other parsers
Low priority
------------
- ``when T is int`` for generic code
- ``when validCode( proc () )`` for generic code
- macros: ``typecheck`` pragma; this allows transformations based on types!
- find a way for easy constructors and destructors; (destructors are much more
important than constructors)
- code generated for type information is wasteful
Other ideas
-----------
- startsWith `=^`
- endsWith `=$`
- ignore case `=?` --> `=$?` too?
|