I wonder why you didn't use LLVM to help make your language?
The Wake Programming Language
31–40 of 58 posts
Re: The Wake Programming Language
#32I wonder why you didn't use LLVM to help make your language?
Great question! I wanted to compile to js with a better interface than emscripten.
Re: The Wake Programming Language
#33I'm not sure I like the closure syntax, with the explicit return. Most modern languages (Swift, Rust, Python (lambdas), Lisp if I can call it modern) support implicit returns and it looks much better. Maybe it's just the juxtaposition with the JS code, but I was confused for a second by the word "return" inside the closure, thinking that it returned from the original function with just the first result. (I really lik…
I hate implicit returns and don't even want them to be possible. A return is a major event. It's clearly a matter of taste.
Re: The Wake Programming Language
#34I wonder why you didn't use LLVM to help make your language?
Been there, done that --- my own pet programming language (we all do one, or several) is Cowbel, at http://cowbel.sf.net, and it's now on its third incarnation, generating C. The second used LLVM.
The reasons I switched away from LLVM are:
- the LLVM API is huge, not very well documented, and changes radically from version to version. - LLVM library consumers are not well supported by the project. Frequently what you get when install it is a set of static libraries, which take forever to link against and lead to 150MB binaries. - LLVM's supported architectures set isn't great yet. C provides a portable, vendor-neutral intermediate language which works everywhere and is easy to read and therefore debug. - targeting C makes library integration trivial (as your output program can use the library's own headers, which means ABI issues become nonexistent).
I did contemplate a partial switch, where my compiler didn't link against LLVM at all but instead just spat out LLVM bitcode assembly --- but emitting C was the same amount of work and so much more flexible. The only downsides is that C can't do tail calls, and getting the debug information to match up is more work, but that's about it.
(For the interested: Cowbel is an experiment at producing a minimal static duck-typed language --- all types are anonymous; you refer to objects only by their interfaces. The compiler than uses type inference to determine the actual concrete type of the object. This allows it to, e.g. use a single machine word to represent a number if you're never going to do dynamic dispatch on it, which means you don't end up with the weird schizophrenia of C++ and Java where some types are scalars and some are objects and they have different semantics.
It's also an attempt at minimalism; I wanted to remove as many features as possible and still end up with a expressive language with Javascript-ish syntax. I'm really proud of the way I managed to unify scope blocks and objects...
It works beautifully, and produces tight, fast code, but the compiler became unmaintainably complex and needs to be rewritten from scratch, which I haven't done yet.)
Re: The Wake Programming Language
#35As a PL designer, there is a lot to like here; the design seems quite reasonable and thought out.
But what I really like is the presentation: I like how all features are summarized, pointing out what is novel, and then everything is just discussed using examples and comparisons to other languages. This is something I'll have to try when I finally get my own language off the ground :).
I wonder if the author is interested in engaging with researchy PL designers. E.g. the testability orientation of the language would make for a good Onward paper, or maybe a Future of Programming workshop presentation.
Re: The Wake Programming Language
#36As a PL designer, there is a lot to like here; the design seems quite reasonable and thought out. But what I really like is the presentation: I like how all features are summarized, pointing out what is novel, and then everything is just discussed using examples and comparisons to other languages. This is something I'll have to try when I finally get my own language off the ground :). I wonder if the author is intere…
I'd absolutely be interested in that type of engagement, papers, and presentations.
I haven't written a technical paper before, but tried to make one on the testability here: https://docs.google.com/document/d/1hT761Cl2-r7cSJV4zR69PGAD...
Re: The Wake Programming Language
#37As a PL designer, there is a lot to like here; the design seems quite reasonable and thought out. But what I really like is the presentation: I like how all features are summarized, pointing out what is novel, and then everything is just discussed using examples and comparisons to other languages. This is something I'll have to try when I finally get my own language off the ground :). I wonder if the author is intere…
I'd absolutely be interested in that type of engagement, papers, and presentations. I haven't written a technical paper before, but tried to make one on the testability here: https://docs.google.com/document/d/1hT761Cl2-r7cSJV4zR69PGAD...
The Onward! deadline is early April (SPLASH will be in Pittsburgh in late October); the future of programming workshop (or whatever we call it) deadline will be sometime much later than that (maybe July?) and the presentation format will probably be flexible (video, paper, ...) with tracks at both strangeloop and SPLASH.
Re: The Wake Programming Language
#38Earlier quoted context omitted.
I'd absolutely be interested in that type of engagement, papers, and presentations. I haven't written a technical paper before, but tried to make one on the testability here: https://docs.google.com/document/d/1hT761Cl2-r7cSJV4zR69PGAD...
The Onward! deadline is early April (SPLASH will be in Pittsburgh in late October); the future of programming workshop (or whatever we call it) deadline will be sometime much later than that (maybe July?) and the presentation format will probably be flexible (video, paper, ...) with tracks at both strangeloop and SPLASH.
Thanks! These are great resources for some cool programs and I will be sure to submit!
Re: The Wake Programming Language
#39The Javascript-for-comparison would help the case better if it didn't look unfairly poorly-coded. (And it doesn't express quite the same logic, though I don't think that makes it look worse here.) I'd have written
function RecordValidator(sessionHolder) {
function validateRecords(records) {
return records.every(validate);
}
function validateRecord(record) {
if (record.lastRevision !== undefined
&& record.lastRevision.user !== undefined) {
return record.lastRevision.user.getAccounts().every(function(account) {
return sessionHolder.hasAccount(account);
});
}
return record.revisions.map(usesLimits);
}
function usesLimits(revision) {
return sessionHolder.hasUser(revision.user);
}
return {
validateRecords: validateRecords,
validateRecord: validateRecord,
usesLimits: usesLimits,
};
}
Re: The Wake Programming Language
#40> Code as concise as javascript, with inheritance and typesafety and more Extremely minor potential nitpick: correct me if I'm wrong, but I think this sentence implies that Javascript is not type-safe, when it is indeed type-safe; it's just dynamically typed, and its type system gives meaning to all expressions (where that meaning is to signal an error in some cases).
http://en.wikipedia.org/wiki/Type_safety
Aggressive type coercion is not type safety. It does not prevent type errors. It just sweeps them under the rug.
5 - 'foo'