blob: 1f1c313011fbebcaae918d1848d0b232a9ca02f3 (
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
|
* thread support: threadvar on Windows seems broken;
add --deadlock_prevention:on|off switch
- implicit ref/ptr->var conversion
High priority (version 0.9.0)
=============================
- 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 implicit generic routines
- fix the streams implementation so that it uses methods
- fix overloading resolution
- wrong co-/contravariance
- make ^ available as operator
- iterators should not always be destructive
Bugs
----
- proc (x: int) is passable to proc (x: var int) !?
- the parser allows empty object case branches
- Exception matching needs to take subclasses into account
- 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...
To implement
------------
* hash tables and sets; count tables; ordered dicts
* 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
------------
- 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
Library
-------
- 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?
|