Nimrod language

[Chad J]

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 at 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!