Implementing a programming language in D: Lexical Analysis
blog.felixangell.com
blog.felixangell.com
I'm wondering why you used D rather than Rust? Was it just that you were curious about the D language or is there something about Rust that you don't like?
https://github.com/aswyk/oxidation/blob/master/oxidation/src...
Of course, Rust's own lexer is also written in Rust.
ETA: I can't promise my lexer is actually any good... it's really the first non-trivial thing I've written in Rust. But it works ;)
I continue to dabble in Rust, but D is so much more comfortable.
enum MyLanguage {
Var(String),
Int(i32),
Sum(Box<MyLang>, Box<MyLang>),
Let(String, Box<MyLang>, Box<MyLang>)
}
Seems like without a construct like this, you'd have to use subclasses or something similar, which (to me) isn't quite as nice.
alias MyLanguage = VariantN!(<insert types here>);
edit: not that it proves anything, just that "it can eventually be done".
enum ConnState {
Disconnected,
Connecting,
Connected(net::TcpSocket),
Transferring(net::TcpSocket),
} import std.typecons;
import std.socket;
import std.variant;
struct Disconnected {}
struct Connecting {}
alias Connected = Typedef!(TcpSocket, null, "connected");
alias Transferring = Typedef!(TcpSocket, null, "transferring");
alias ConnState = Algebraic!(Disconnected, Connecting, Connected, Transferring);
You can create such new types with std.typecons.Typedef https://dlang.org/phobos/std_typecons.html#.Typedef
Though it's less pretty.
I recently came upon this post and couldn't agree more with it: https://www.quora.com/Which-language-has-the-brightest-futur...
I prefer meta-programming in D as I don't get to think at the AST level; its practical in Lisp because the code is the AST, but everywhere else I like compile-time function evaluation better - it feels more natural. It's the same reason why I don't like template-Haskell.
D also has string mixins for the rare occasion when templates reach their limits. You get something akin to "eval" in javascript, but as a compile-time construct. Mixed with the other compile-time features of D (function evaluation, reading files, full reflection and more) it makes for the most powerful thing I know of after Lisp macros. I never have to write offline code analyzers and generators again!
I prefer interfacing with C in D because I don't get to mess with a FFI; I can copy/paste the C definitions in D, run a few Emacs macros and I'm good to go. (Although that's becoming a non-issue over time as more and more bindings are published!)
As far as I know (correct me if I'm wrong!) there's no way to declare pure functions in Nim. This is something I do all the time in D!
Nim has memory-safety only when using the GC while D has decoupled it from the allocation strategy. D's memory-safety is actually part of the type-system (as function annotations) and I absolutely love it!
That's about what comes to mind right now :)
Please note that these points merely makes D a better fit for my own use-cases, I'm also biased from knowing D a whole lot more than Nim, so take what I say with a grain of salt ;)
Nim includes templates (declarative metaprogramming), and macros (procedural metaprogramming). The latter gives you access to Nim's AST. Macros (and compile-time functions) are evaluated using Nim's VM. The VM supports the full language, with the exception of FFI, but you do get special compile-time functions for reading files and executing external processes at compile-time so it's already very powerful!
Nim compiles to C/C++ so interfacing with C (and C++) could not get easier. Have not tried writing a macro for my editor which converts a C definition into Nim, sounds like a fun thing to implement.
> As far as I know (correct me if I'm wrong!) there's no way to declare pure functions in Nim. This is something I do all the time in D!
By pure I assume you mean "side-effect free"? If so there is: http://nim-lang.org/docs/manual.html#pragmas-nosideeffect-pr...
> Nim has memory-safety only when using the GC while D has decoupled it from the allocation strategy. D's memory-safety is actually part of the type-system (as function annotations) and I absolutely love it!
Going to need to look into that. Sounds awesome!
In any case, you should definitely give Nim another chance. I can certainly say that I will do the same for D :) Thank you for taking the time to write this up!
I'm also glad to see Nim having purity, its incredibly hard to go back once you've tasted it!
The Emacs macros I mentioned aren't saved anywhere; the similarities in syntax between C and D makes it very straightforward to write dumb macros on-the-fly and forget them afterwards. For the most part D improves on C's syntax by fixing a lot of its shortcomings and the macros merely reflect that.
One example would be to convert "#define foo 1" into "foo = 1," to be put inside an enum declaration. Another would be to remove the DLL_EXPORT references (as D does not require them). The function definitions themselves barely change at all :)
One thing I'm also curious about are compilation times. My D program still compiles under 2-3 seconds even with recursive reflection of 100+ aggregate types, outputting meta-data and code for every single type and field (to handle serialization, generate on-screen editors, resolve dependency graphs and more). I haven't found any other systems language giving me this much power for this little compilation times.
This even includes transforming my regex expressions into D code during compilation so the regexes get the full power of the language's optimizer.
I'll definitely keep Nim in mind for my next pet project, right now I'm getting over 30k LoCs in my D project and really don't want to switch languages halfway through! :)