gokr

And if you like Rebol you should. Spry is nowhere near as evolved as Red (which is darn impressive) and Spry is also moving towards Smalltalk more than Rebol.

I also think there is quite a bit of difference in philosophy. Rebol/Red loves adding tons of hardwired datatypes into the language, while Spry is more Lisp/Smalltalkish in minimalism. Also, Rebol shunned OO which Spry doesn't (Red... not so sure).

But shunning OO is popular these days :)

And yeah, Parse is very interesting. I would like to do something similar in Spry but perhaps borrowing more from PetitParser (a very nice parser combinator library in Smalltalk from Lukas Renggli)

funci for infix. func for prefix. May end up changing that.

Thanks! And oh, for longer discussions do pop in on gitter, gokr/spry. Some attempts at answers:

Yes, the select: there is not polymorphic, it's simply a function (as of right now).

clone is a primitive function, can be seen here: https://github.com/gokr/spry/blob/master/src/spryvm.nim#L180... (search for "clone" on that page to find the Nim implementations for the various basic node types)

whileFalse: is also a primitive and can be seen here: https://github.com/gokr/spry/blob/master/src/spryvm.nim#L190...

So yes, these are examples of primitive Spry functions that are implemented in Nim.

Regarding the larger question, you can implement control structures in Spry, but they are obviously quite a lot slower. Also, it's worth noting that whileTrue: and friends are normally in Smalltalk implemented using special case bytecode tricks (jump).

But you are correct in wondering about polymorphism, and Rebol doesn't AFAIK have anything like it - Carl shunned OO when creating Rebol. In Spry I am working on a concept of tags and what I call polyfuncs. Any node can have one or more tags added to it and functions can have multiple sub functions dispatched over based on these tags. The basics of this already works:

https://github.com/gokr/spry/blob/master/src/sprytest.nim#L4...

Hard to read I guess, but it basically creates a polymorphic function "inc" that has two different sub funcs selected based on the tag of the receiver.

So about "design principle" - both yes and no. Spry is more "shallow" than typical Smalltalks because Spry is being implemented much more tightly together with Nim. This is by design, it makes it MUCH easier to make primitives and to interface with Nim and thus also C/C++. It's already trivial to do, and a lot of the examples show that. But I also want Spry to feel similarly "coherent" as Smalltalk does.

And yes, definitely will describe the block/list thing in the manual. Too bad this HN post happened before the manual is out there, but oh well.

But generally this is what homoiconicity means - code is in the same format as the core data structures. You can thus create and manipulate code as lists - just as in Lisp.

And also, the block [echo :x] doesn't use declarations of parameters - instead the ":x" is an operation that pulls in the next argument from the call site and stores it into the local binding x in the closure. Almost Forth-ish, but there is no stack.

Yes, correct. It's worth noting that echo is a prefix function so Spry supports both infix (first argument is on the left) and prefix functions, and if there is a series of keywords the parser will rewrite the keyword call to a prefix/infix call like this:

array at: 1 put: 2 ==> array at:put: 1 2

Thus a keyword call is purely syntactic sugar.

Just curious about what you refer to as "excessive punctuation"? You mean blocks []?

There are no statement separators (!) in Spry and the grammar is very, very minimalistic. You could argue in some ways Spry is "a Lisp without parenthesis", and although I like indentation (Nim uses it) for scoping I also find Smalltalk VERY readable.

Also, it's not yet apparent but the syntax/grammar of Spry (and homoiconicity) makes it very suitable for DSL construction, very much similar to Rebol/Red.

(author of Spry) Just a few notes:

I like the cleanliness of Lisp, but I have always found it hard to read. That's one reason for Spry to have a bit more syntactic elements than Lisp.

Spry supports both prefix and keyword style function calls, although as a Smalltalker by heart I favour keyword style.

Finally, Spry is still an evolving experiment. Next up is the OO model which I hope will be interesting.

You can play around with Nim for getting some numbers on this - since it can compile to C, C++ or js.

IMHO it's not worthless. Nim has ptr and addr, but they are explicitly described as unsafe and only used "when you have to", like interfacing with C/C++ etc. I have never used them outside of C/C++ integration. Rust also has unsafe, but I presume you don't think that invalidates safety.

See my comment https://news.ycombinator.com/item?id=10992077

It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.

I also found several items in Pony to be interesting, and Andreas is very aware of Pony. One drawback of Pony is that it is written in C, while Nim is written in Nim. But a lot of the concepts in Pony are worth looking hard at :)

No, you get Nim source code debugging using line number directives etc, works great including breakpoints and all. I have tested several IDEs and it works. But data inspection does generally not work - that would require some work to support GDB protocols.

Thank you for clearing that up - I have always been confused when pcwalton has written (a bunch of times) that "Nim's GC isn't thread safe" - since... I knew about the deep serialization and couldn't for my life understand why it wouldn't be safe then.

But how could the segfaults then happen? Aha, you mean the test code perhaps shared via globals?

I still don't see it. You wrote "Nim claims it's secure" and I wonder where Nim does that. What I do see is careful explanations in the language manual what is safe and what is not. I am not even remotely as sharp as pcwalton, Araq or Jehan/rbehrends when it comes to these things, but my perception of what "Nim says" is basically "if you use these things, you should be ok. If you use these other things, you are in C country." Then of course modulo bugs and wip stuff. It is perhaps a different philosophy at play.

But I am genuinely interested in where this claim is made, perhaps we need to adjust some documentation or make things more clear - so do point us to it if you find it again.

Two links that you may have seen: http://forum.nim-lang.org/t/658 http://disconnected.systems/nim-on-arduino/

Debugging via gdb and frontends using gdb like KDevelop or QtCreator works very well - except data drilling. But that may be solved eventually.

Just curious since I must have missed it - where is this claimed? On nim-lang.org? And yes, Nim is not 1.0 yet so some areas are still evolving. And no, I don't think I asked anything?

The creator? I may be daft but that is someone saying he/she has been using Nim for one year?

Great! Thing is, Rust and Nim are very different. Just as I wouldn't put Rust down for not having GC (I love languages moving the art forward) I just wish we could look at Nim as a language with different design goals than Rust. I know several things in Nim worth discussing, it doesn't have to be warring.

Note though that C++ is something very different. And c2nim can produce C++ wrappers, see for example Urhonimo, a Nim wrapper of Urhod3D. Of course this is a benefit from going via C/C++ offsetting the disadvantage. Btw, I am not negative towards Rust, although I prefer Nim for my use cases (but eventually I will try Rust) - I just wish people could view and critique languages from their respective design goals.

Sure, and I can apologize for my wording in advance too! But I do stand by my opinion that he doesn't have to drop that in every single time Nim is mentioned. Evidently Go-people feel the same I noticed.

About safe/undefined etc I think it has been answered before (there are probably more places): https://news.ycombinator.com/item?id=9643690

Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :)

But... generally, I would say all these languages can replace each other (well, ok, perhaps not C) given the right circumstances. Nim has one nice thing going for it - and that is very good C/C++ integration. Rust has it's safety focus and novel memory model. Go has simplicity and tooling, and popularity. Java has enterprise-focus. All have good performance.

Great work man! I will get one for sure.

Nim compiles to very efficient C or C++ (or js) and most benchmarks shows Nim programs performance being almost the exact same as C/C++ - and often better than Rust.

So... why not using it to replace C and C++? Since I have worked with Nim (and I use it to implement my own language) I would say "hell yes"! It is such an immensely better language and it integrates perfectly with those eco systems. The GC is a good one (or well, there are 5 to choose from) and it is for many, many applications not an issue.

And before pcwalton drops in with his endless spamming about Nim not being safe, Nim being undefined etc etc (it's getting quite annoying), please spare us this time.

I can however mention that with the Urhonimo project (currently dormant, but still quite cool) we had no issues with using the C++ backend. Although Andreas did make a bunch of improvements to c2nim and perhaps the Nim compiler too IIRC.

And oh, notice there actually is an LLVM backend brewing now!

Ha! That's funny, noone has noticed that before you :) I wonder if I was thinking of a fifth or not...

I will fix it, Nimrod was renamed.

Nothing prevents you from static linking AFAIK:

https://www.schipplock.software/p/static-linking-with-nim.ht...

Googling a bit finds more on the subject, for example to go very small:

http://hookrace.net/blog/nim-binary-size/