5 ms·
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
by eriksvedang 10y ago
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
- Pxtl 10y agoIs the plan for this to be a stand-alone gaming language or a language for embedding into a gaming engine or framework like Lua? Obviously built-in threading constructs are less essential for the latter.
- eriksvedang 10y agoPrimarily stand-alone.
- cbebdhhd 10y agoCould 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 to infer parentheses based on code indentation. Also have you considered compile time AST evaluation and simplification?
- imtringued 10y agoIf you don't want the parenthesis then why not use reverse polish notation?
- blastrat 10y agounless you're thinking of something that I'm not thinking of? RPN only solves this when the operators are known and used exclusively in operator context and can be relied on as implied close-parens
- larsbrinkhoff 10y agoMaybe you can use "Readable Lisp S-expressions". http://readable.sourceforge.net/ http://readable.sourceforge.net/
- akavel 10y agoIf it takes off, and fulfills all peoples' dreams and brings rainbow-farting pink ponies to Earth, then I suppose there might come lots of parser butchering by people and fitting it to their likes via forks/frontends - me, for example, I'd love it to look more Rebol-like ;)
- akavel 10y agoThanks! Re 1: are there any examples of this in the codebase? I haven't seen anything in the "examples/" subdir, did I overlook, or should I dive somewhere into the compiler/runtime codebase? Also, some more questions still, if you wouldn't mind: • Could you possibly answer junke's question? https://news.ycombinator.com/item?id=12041555 https://news.ycombinator.com/item?id=12041555 I didn't repeat it, as I hoped you'd see it too; • Do you have tail-recursion? Also, to tell the truth, a list of "what we don't have yet" and also "what we don't plan to have" would help to confront my dreams with reality... Regarding (2), personally I like Go's/Rust's approach, but I'm not an expert in the domain by any means, and I understand everybody has one's personal taste and view. Just couldn't resist, sorry :) edit: Also I see you're the author of Else Heart.Break() - awesome, congrats!
- eriksvedang 10y agoNo tail recursion at the moment but it's something I'd be interested in adding later. I'm being very conservative with adding different type constructs but sure, Rust & Go certainly gets a lot of things right in that department and I'll consider their solutions for the future development of Carp.
- nickpsecurity 10y agoNeat to see a contender to replace what should've had plenty of adoption in this area: https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme I still don't see a clear answer to junkie's question despite a huge thread. Let's be specific: "Where no GC is used, how exactly do you handle the issue of memory safety? Is it no safety like C, a specific analysis like Rust, or something different entirely?" Far as concurrency, you probably know about Rust's scheme. The ones that came before it that you might want to consider were Ada Ravenscar and Eiffel's SCOOP. https://en.wikipedia.org/wiki/Ravenscar_profile https://en.wikipedia.org/wiki/Ravenscar_profile http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf http://www.sigada.org/ada_letters/jun2004/ravenscar_article.... https://en.wikipedia.org/wiki/SCOOP_(software) https://en.wikipedia.org/wiki/SCOOP_(software) http://cme.ethz.ch/publications/ http://cme.ethz.ch/publications/ SCOOP might be the more interesting of the two for you. It was deployed in real-world apps in Eiffel first. Then, a team ported it to Java. It had a performance penalty. One of the many works in publications... don't remember which... did something ("slices?") that knocked out almost all that overhead. Another model-checked it to eliminate a few errors in SCOOP model. I see one on message-passing. So much badass work and results on SCOOP model I've been annoyed that it was ignored by mainstream for so long. So, hope those help in your thinking on tackling concurrency. Personally glad I looked it up for you as I found this very, interesting project for safe use of GPU's: http://se.inf.ethz.ch/people/poskitt/publications/Kolesnichenko-PNM.GPCE.2015.pdf http://se.inf.ethz.ch/people/poskitt/publications/Kolesniche...