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" <lug...@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!
