>
> D implements slices as (ptr, length) pairs which causes issues for a GC
> as that invites lots of interior pointers and GCs tend to have problems
> with those, causing at least some overhead in the GC/memory system.
>

The site says Nimrod allows for soft-realtime. Could you talk more about the GC.

> The site says Nimrod allows for soft-realtime. Could you talk more about the GC.

It didn't make it into 0.8.14 and afaik hasn't been used within a game engine yet. But it has been tested with the compiler itself with very good results: A 2ms max pause time was met in all cases (on modern hardware).

Documentation is here: https://github.com/Araq/Nimrod/blob/master/doc/gc.txt

On 05/28/2012 04:21 AM, Araq wrote:
> On Saturday, 26 May 2012 at 11:49:47 UTC, Chad J wrote:
>> On 05/24/2012 07:21 PM, Araq wrote:
>>> On Thursday, 24 May 2012 at 22:56:52 UTC, Kevin Cox wrote:
>>>> On May 24, 2012 6:53 PM, "Froglegs" <lugtug@yahoo.com> wrote:
>>>>
>>> Nimrod is full of constructs that have inlining semantics and as such
>>> declaration order matters quite a bit. The D compiler has/had bugs with
>>> this feature for a reason. ;-)
>>
>> OK, now I'm curious. Why?
>>
>
> Because it's hard to implement? ;-)
>
>
> t() # the compiler needs to *expand* t here; parsing t's
> # header and put it into the symbol table is not enough
>
> template t() = ...
>

I'm reading this to mean that t might contain other definitions, so building a symbol table to completion would involve leapfrogging template/macro expansion with symbol table invalidation/insertions.  At some level though, I expect the compiler to do this for me.

>
> And Nimrod supports symbol table inspection:
>
> when not defined(p):
> proc p = echo "a"
> else:
> proc p = echo "b"
> p() # what should that do?
>
> These things can be solved, but it's lots of work and I have no idea how
> the result would affect compile times (probably negligible).
>
>

p() should print "a": p wasn't defined to begin with.  It wouldn't be intuitive to me if the when statement is evaluated more than once, not unless it's found within a macro or something that iterates.

>>> I'm considering to weaken the requirement but I don't mind this feature:
>>> Having the order reflect the call graph has its advantages too. Many
>>> consider the resulting order *backwards*, but at least there is *an*
>>> order.
>>>
>>
>> Wouldn't it be good enough to define the order arbitrarily when
>> building your symbol table? What kind of information is this allowing
>> the programmer to convey to the compiler?
>>
>
> I was talking about readability here. You can read an ordinary
> (smallish) Nimrod program from *bottom to top*. (And a forward
> declaration often screams "warning: mutually recursive procs ahead").
> Granted, from *top to bottom* would be nicer, but I have never seen that
> happen in practice in C# (which allows for arbitrary order); but
> admittedly that's a very weak point.
>

But... I like my arbitrary ordering.  I don't necessarily define functions according to their call graph, but instead with functionality groupings and mnemonics.

>> I'm already skeptical because I have no intuition for how this allows
>> me to better optimize my code ;)
>
>> Btw, I've looked at Nimrod a while ago (year+) and found it very
>> elegant. I love good metaprogramming. I think my only complaints were
>> the bus-factor and the apparent lack of array slices (the kind that
>> doesn't cause copying). Still, very promising.
>
> See my other answer about the slicing. The bus factor got better as
> there are now 3 core developers. :-)
>

Congrats!

* Can you do metaprogramming with nimrod templates? Are they as powerful as C++/D in this regard? Docs for templates is very short, making me think you can't do much, but perhaps it just isn't covered?

*also what is up with lack of unsigned integer types?

*not a big fan of forward declaring things, just seems very primitive, something the compiler should do

*can you create unnamed procs?


+see closures is upcoming, that should be nice

On Sunday, 2 January 2011 at 06:46:46 UTC, bearophile wrote:
> That fantasy of yours means that I am interested in using my time to explain to Nimrod developers what's good in D, what may be modified or improved, to steal some of the good ideas of the D language for the development and spreading of Nimrod :-)

Huh, system pl with python syntax, it's your dream, isn't it?

On Monday, 28 May 2012 at 08:21:36 UTC, Araq wrote:
> Granted, from *top to bottom* would be nicer, but I have never seen that happen in practice in C# (which allows for arbitrary order); but admittedly that's a very weak point.

I wrote tons of C# and I never did it bottom to top. They're either thematically grouped or top to bottom (e.g. Main comes first). "Extract method" refactoring also places extracted method after the method it was extracted from.

On Tuesday, 29 May 2012 at 08:00:11 UTC, Froglegs wrote:
>
> * Can you do metaprogramming with nimrod templates? Are they as powerful as C++/D in this regard? Docs for templates is very short, making me think you can't do much, but perhaps it just isn't covered?
>
Yes docs are sparse for now. It is (or will be) as powerful as C++/D in this regard.

> *also what is up with lack of unsigned integer types?
>
They will be added, don't worry. In fact, they can already be implemented in a pure library form. I wanted to prevent programmers from using them (as "unsigned" is *not* the same as "natural" and is bug prone), so leaving them out seemed a good means to accomplish that. ;-)

> *not a big fan of forward declaring things, just seems very primitive, something the compiler should do
>
As I said, its priority is low.

> *can you create unnamed procs?
>
Yes.