11–20 of 71 posts
It really looks like a great language!
Hmm I actually like the fact that the arguments of a function are defined using square brackets. It just reminds me of Clojure, especially the "defn" macro, which sounds pleasant to me. I wonder what Lispers would say about that since I heard that not having a homoiconic syntax might cause some troubles at metaprogramming(macro) level.
It is homoiconic, because the data structures used to describe code are also data structure provided by the language. However, brackets mean that you pass arguments as arrays instead of lists: there is little reason except aesthetics to have this distinction in source code. I prefer parenthesis everywhere, but some people really dislike that.
Are all those round brackets necessary? I understand the goal is Lisp like syntax. But while reading the OpenGL sample, I found the enclosing brackets quite unintuitive. Since this is still supposed to be new language may be "statically typed Lisp with python-like blocks" will appeal to a larger audience?
I understand this is marked as "a research project", so any answer here is possible and must be accepted; that said I'd really love to learn at least about plans with respect to the following questions: • Regarding FFI, is it possible to pass pointers to carp functions/closures as arguments to external dynamically loaded functions? are those features available in REPL? • What's the story/approach regarding structs in…
2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon
3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write
Thanks, Erik
Hmm I actually like the fact that the arguments of a function are defined using square brackets. It just reminds me of Clojure, especially the "defn" macro, which sounds pleasant to me. I wonder what Lispers would say about that since I heard that not having a homoiconic syntax might cause some troubles at metaprogramming(macro) level.
It is homoiconic, because the data structures used to describe code are also data structure provided by the language. However, brackets mean that you pass arguments as arrays instead of lists: there is little reason except aesthetics to have this distinction in source code. I prefer parenthesis everywhere, but some people really dislike that.
I think vectors for argument lists is mainly a usability affordance. Which gives you aesthetics for free. (If you happen to find it more aesthetic.)
> Common LISP and Scheme are not simple in this sense, in their use of parens because the use of parentheses in those languages is overloaded. Parens wrap calls. They wrap grouping. They wrap data structures. And that overloading is a form of complexity by the definition I gave you. (https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)
Elsewhere, he critiques Clojure's use of vectors for argument lists. Because a vector implies order, so every caller must put arguments in the right order. (To decomplect, you'd use maps instead of vectors. But vectors win you brevity. Many notice that with longer argument lists, maps increasingly become more attractive than long argument lists.)
Are all those round brackets necessary? I understand the goal is Lisp like syntax. But while reading the OpenGL sample, I found the enclosing brackets quite unintuitive. Since this is still supposed to be new language may be "statically typed Lisp with python-like blocks" will appeal to a larger audience?
For example, you can automatically convert back and forth between s-expressions and something else, like i-expressions http://srfi.schemers.org/srfi-49/srfi-49.html
I understand this is marked as "a research project", so any answer here is possible and must be accepted; that said I'd really love to learn at least about plans with respect to the following questions: • Regarding FFI, is it possible to pass pointers to carp functions/closures as arguments to external dynamically loaded functions? are those features available in REPL? • What's the story/approach regarding structs in…
1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik
I was originally envisioning having the compiler being able to infer parentheses based on code indentation.
Also have you considered compile time AST evaluation and simplification?
Earlier quoted context omitted.
It is homoiconic, because the data structures used to describe code are also data structure provided by the language. However, brackets mean that you pass arguments as arrays instead of lists: there is little reason except aesthetics to have this distinction in source code. I prefer parenthesis everywhere, but some people really dislike that.
In most Scheme implementations, which this Lisp somewhat resembles, it's permissible to use "(" or "[" as long as the opening bracket matches the closing one. With that choice, each user can have the "esthetic" that is preferred. Personally, I agree that using parentheses exclusively is nicest, but it's not that big a deal either way.
Earlier quoted context omitted.
1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik
Could you pretty, pretty please allow for an option to have automatic parentheses insertion, similar to how javascript will insert semicolons, making them optional? This is almost exactly the language that I've been planning for the last six months, and if you would be so kind as to implement that one feature, it would save me a lot of reinventing the wheel. I was originally envisioning having the compiler being able…