Usually I love looking through new programming languages, but the docs here don't give me any motivation for the language, or even any reasonably non-trivial examples. Is it just supposed to be C++ with Lots of Irritating Silly Parens?
I had a brief look at the solutions of the problems from Project Euler in L++ [0]. As you say, it seems like C++ with the LISP syntax. On the other hand, it can be a LISP where you can trivially import some C++ libraries (as in the source code: (include "iostream" "vector") ). But since I couldn't find macros and eval in the docs, I would err on the side of C++ with the Silly Parens for now...
A Lisp dialect that compiles to C++ is interesting. I am not sure if features like Lisp macros would be provided, but still you can compare the versions of 99 bottles of Beer and see a significant difference: http://www.99-bottles-of-beer.net/language-c++-111.html
I find the L++ version to be very way more elegant.
Well, yeah, an actual example of realistic code is going to be more elegant than something that's literally self-parody.
int main()
{
for (int i = 99; i--;) {
std::cout << i << " bottles of beer on the wall, " << i << " bottles of beer.\n"
<< "Take one down, pass it around, " << i << " bottle of beer on the wall.";
}
}
is basically the same thing as the L++ version, with a few added bitshift operators.
I thought silly parentheses are just as easy to parse as in an imperative language like C. Are you referring to the Polish prefix form being easy to parse?
It's more like, the text is easier to turn into an AST, and it's easier to manipulate that AST. It's not so much the parens, but the nested structure (and that all of the code is in that structure)
> It's not so much the parens, but the nested structure (and that all of the code is in that structure)
I should have explained myself more clearly, I thought that the operator appearing at the beginning of the list means that operator precedence is no longer relevant. With infix operators the precedence is important.
Infix languages are trivial to parse; undergrad CS students typically do it the same week that they learn about parsing prefix and postfix languages.
What actually makes lisps easy to parse is a near complete absence of syntax; particularly structures/constructs that require considerable effort to disambiguate.
It does not. Nearly all of the common-lisp to C transpilers are decedents of Kyoto Common Lisp. One notable exception is mocl, which I believe to be a decendent of CLiCC (http://www.informatik.uni-kiel.de/~wg/clicc.html)
Racket is so much fun. A single rkt file to C++ transpiler? Awesome stuff.
Anyone who has done things like this before: is it peformant? The Racket documentation mentions against compiling out C/C++ sources it can emit, because it misses the JIT and other optimizations. Would the emitted C++ code be worthwhile?
Ironically, this seems to be exactly what Naught Dog was doing for the infamous Racket on PS3 talk, even though it was not actually running on the PS3 (it was MzScheme that transpiled to C++ code that could be compiled to patch together game demos).
Depends on your use. For open source work, Github's community probably makes it better. For closed source, personal work, as mentioned elsewhere, only being limited by size of repos is much better. For a business, I suppose it depends: Bitbucket is part of Atlassian, a company many development shops already interact with, however, the Github community can be a good source for recruiting.
To whoever down voted my earlier comment, linked here [0], thank you for responding to my query, I'm guessing that you consider bit-bucket not to be superior to git-hub.
It could have been easier if you just replied to the comment, then I wouldn't have to extrapolate an answer.
I didn't downvote you, but I suspect the reason you were downvoted was because it was off topic - we are talking about a new dialect of Lisp here, not github and bitbucket.
For those interested in C++ and lisp, there is someone who has a nearly complete common-lisp implementation written in C++, with a strong focus on easy calling to C++ (Which is a serious weakness of the FFI for most languages, Lisp included). I don't know if there is an ETA for it being released yet though.
44 comments
[ 11.0 ms ] story [ 1514 ms ] thread[0]: https://bitbucket.org/ktg/l/src/cb93b589c03ec1e39007c1907deb...
I find the L++ version to be very way more elegant.
Edit: More examples... https://bitbucket.org/ktg/l/src/cb93b589c03ec1e39007c1907deb...
If there were Lisp-style Macros available, that would beat the pants off the C Preprocessor for boilerplate.
I thought silly parentheses are just as easy to parse as in an imperative language like C. Are you referring to the Polish prefix form being easy to parse?
I should have explained myself more clearly, I thought that the operator appearing at the beginning of the list means that operator precedence is no longer relevant. With infix operators the precedence is important.
What actually makes lisps easy to parse is a near complete absence of syntax; particularly structures/constructs that require considerable effort to disambiguate.
http://en.wikipedia.org/wiki/Homoiconicity
In fact it uses Racket behind the scenes which might open the door to use regular Lisp features.
"The golden rule of CoffeeScript is: 'It's just JavaScript'"
https://bitbucket.org/ktg/l/src/cb93b589c03ec1e39007c1907deb...
The L++ source also looks very much like this lovely write-up on how to write a Scheme x86 compiler: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf
Anyone who has done things like this before: is it peformant? The Racket documentation mentions against compiling out C/C++ sources it can emit, because it misses the JIT and other optimizations. Would the emitted C++ code be worthwhile?
Ironically, this seems to be exactly what Naught Dog was doing for the infamous Racket on PS3 talk, even though it was not actually running on the PS3 (it was MzScheme that transpiled to C++ code that could be compiled to patch together game demos).
It could have been easier if you just replied to the comment, then I wouldn't have to extrapolate an answer.
[0] https://news.ycombinator.com/item?id=7712428