Nimrod language

[Araq]

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() = ...


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).


>> 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.

> 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. :-)