<div dir="ltr">On Sun, Jul 20, 2014 at 6:28 PM, Jonas Maebe <span dir="ltr"><<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br></div>
I proposed to use "is block" because of the analogy with the already existing "is nested". Neither "block" nor "nested" was/is/would be a reserved word afterwards, just like many other words that have a special meaning in one context or another (look at compiler/tokens.pas; most tokens are not reserved words".</blockquote>
<div><br></div><div>Yes, true. I should have not used "reserved" term but rather context special words.<br></div><div>And since "is nested" is there, it does make sense to propose "is block". <br>
  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's also a similar concept (you have a pointer to something that describes a function), but it's incompatible and different so you need a different syntax. Any different syntax is fine, as far as I'm concerned.<br>
</blockquote><div></div><div><br>It's just my personal appeal to reuse as many of existing reserved/context words as possible. (In which case "is block" seems better to me, than "reference to"... just because its less typing, though too "block"-specific)<br>
<br></div><div>I'd think that as soon as the feature is added to the trunk, some other source parsing libraries (CodeTools, fpc-passrc) needs to be updated. <br></div></div><br></div><div class="gmail_extra">thanks,<br>
</div><div class="gmail_extra">Dmitry<br></div></div>