Seems working, although lists the same exception several times:
proc genIdFor(o: var TOpenDb; t: TPalTable; n = 1): TEntityId {.
raises: [EDb, EDb], tags: [FReadDb, FWriteDb].}
Have to read about effects and tags, the language is developing so fast I can't catch on.
I hope it won't be the same mess as Walter's/Alexandrescu D1.0->D2.x revolution that many people lost interest because of hunting a moving target and overcomplexity...
I hope it won't be the same mess as Walter's/Alexandrescu D1.0->D2.x revolution that many people lost interest because of hunting a moving target and overcomplexity...
In fact the feature set is mostly frozen (and todo.txt contains the missing pieces), it simply takes a while to implement all of the planned spec... ;-)
BTW whenever I go for simplicity (leaving out traditional OO features; requiring forward declarations) people complain ...
I hope it won't be the same mess as Walter's/Alexandrescu D1.0->D2.x revolution that many people lost interest because of hunting a moving target and overcomplexity...
yes they have really a hard time to find meaningful keywords, as almost everything is deprecated now or has changed its meaning.
BTW whenever I go for simplicity (leaving out traditional OO features; requiring forward declarations) people complain ...
we need to show how to use the flexibility of nimrod to implement missing "features". I highly prefer the simplicity approach and having the freedom to implement these things in code or with macros. The last months I used nimrod were really an eye opener for me, but I know that most of the people will look at the specs and will miss a lot of features they are used to and they won't understand what they can do with AST macros, term rewriting rules, hygienic templates, generic overloading (AST based overloading to come, when I understand the todo.txt right), defining own operators .... The list of uncommon features is long, but does not fit the expectation level of a somehow curious programmer.
I needed at least two different impulses to look deeper into nimrod:
@adrianv, yes, missing features which people are got used to in other languages should be demonstrated with code snippets.
However the absence of those features encourages to go a simpler way and do not overengineer -)
Personally i don't like the idea to implement those complex features like interfaces/annotations etc. with nimrod as a library because those nice macros and templates get used more and more while project grows and finally slow down compilation times tremendously... It's from my experience, at least C++ boost projects are pain to work with. But I like the way templates and generics are implemented in nim.
Compiling to C is a big plus for me because there's no absolute need to write complete bindings to third-party libs. Writing bindings means you have to support them =)
adrianv >but a native compiler would be nice sometimes
A proper bytecode based interpreter that supports the FFI is planned. I don't know if that will help you. ;-)
exhu > Personally i don't like the idea to implement those complex features like interfaces/annotations etc. with nimrod as a library because those nice macros and templates get used more and more while project grows and finally slow down compilation times tremendously... It's from my experience, at least C++ boost projects are pain to work with.
The compiler already supports incremental recompilations via --symbolFiles:on (unfortunately still a bit unstable) and the language is carefully designed to not rely on whole program compilation and that generic instantiations can be cached. I don't think C++ is a good argument of why the approach in general has to result in slow build times.
Araq: A proper bytecode based interpreter that supports the FFI is planned. I don't know if that will help you.
a byte code interpreter would be cool for many purposes. I think of a) debugging possibilities in an IDE b) embedding nimrod code as a scripting language. Since nimrod is strictly and static typed it might be possible to implement the byte code interpreter without the need to box the build in types, which could be a big performance advantage against byte code interpreters build for dynamic typed languages.
Since nimrod is strictly and static typed it might be possible to implement the byte code interpreter without the need to box the build in types...
Yes that's the plan. However a non-boxing implementation is much more work; so much that I in fact consider generating x86_64 (or maybe ARM) opcodes and get a JIT on this platform for free. For the other platforms the opcodes would have to be interpreted/emulated.