<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>p.s. On second thought, for structs you want two constructors:&nbsp;</div><div>&nbsp;-- one that takes positional arguments&nbsp;</div><div>&nbsp;-- one that takes keyword arguments&nbsp;</div><div>but perhaps 'new' can play the role for both:&nbsp;</div><div><br></div><div>&nbsp;(new fisht #:name "Nemo" #:weight 700)</div><div><br></div><div>and&nbsp;</div><div><br></div><div>&nbsp;(new fisht% #:name "Nemo" #:weight 700)</div><div><br></div><div>might work.&nbsp;</div><div><br></div><br><div><div>On Jun 17, 2013, at 10:52 AM, Laurent wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div>Actually I realize I'd like something exactly like `instantiate'.<br></div><div>If instantiate used keywords instead of bindings, and removing the `instantiate' word, we would then even have the exact same syntax for class instantiation and procedure call:<br>

</div></div><div><br>(define nemo (fish% "Nemo" #:age 3)) &nbsp; ; instantiates `fish%'<br></div><br>Of course this could be extended to structs.<br><div><br>This would harmonize different calling mechanisms, as well as being more flexible.<br>

Wouldn't that be nice?<br></div><div><br></div></div>Laurent<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 8:12 AM, Laurent <span dir="ltr">&lt;<a href="mailto:laurent.orseau@gmail.com" target="_blank">laurent.orseau@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt <span dir="ltr">&lt;<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: <br></div></blockquote></div><div class="im">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
&gt; I've always wondered why the syntax of keywords implied two elements: the<br>
&gt; #:keyword and the identifier.<br>
&gt; I find that quite heavy for procedure headers, and most of the time I use<br>
&gt; the same symbol for the identifier and the keyword (and when I don't it's<br>
&gt; because I'm simply lazy and use a shorter identifier).<br>
&gt;<br>
&gt; Is there a rationale somewhere for that?<br>
<br>
</div>The rationale is to make function definitions have the same shape as<br>
function calls.<br></blockquote><div><br></div></div></div>I see what you mean, though I wouldn't make a strong case of it (maybe I'm <br>missing something).<br><br></div><div class="gmail_extra">From time to time, I really feel frustrated by the current function header style.<br>


</div><div class="gmail_extra"><br></div><div class="gmail_extra">What I'd really like, for the sake of flexibility / ease of use, is to<br>have no explicit keyword argument, but all arguments are implicit ones, so <br>


that you can call a function by mixing by position and by name as you like, <br>without having specified so in the function's header.<br></div><div class="gmail_extra">(Visual Basic[1] and Python[2] do something along these lines.)<br>


</div><div class="gmail_extra"><br></div><div class="gmail_extra">For example:<br></div><div class="gmail_extra">(define (foo x y [z 3] [t 4]) ....)<br><br></div><div class="gmail_extra">(foo 1 2 5)<br></div><div class="gmail_extra">


(foo #:z 5 #:y 1 #:x 2)<br></div><div class="gmail_extra">(foo 1 #:t 6 #:y 3)<br><br></div><div class="gmail_extra">(foo #:x 3)<br></div><div class="gmail_extra">Error: missing mandatory argument `y'<br><br></div><div class="gmail_extra">


(apply/kw f 2 #:y 3 '(5) '((t . 3)))<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In particular, one would then not have to worry about the order of the<br>optional arguments in the function definition.<br>


<br></div><div class="gmail_extra">Headers would be also smaller, easier to read, and easier to write.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Pushing a bit further:<br></div><div class="gmail_extra">


(define (foo x y . rest) ....)<br></div><div class="gmail_extra">would not accept keywords different from #:x and #:y, but<br></div><div class="gmail_extra">(define (foo x y . rest-by-pos . rest-by-name) ....)<br></div><div class="gmail_extra">


would receive a list of positional argument values, and a dictionary of <br>names and values, even if these names are not x or y.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">

<br></div><div class="gmail_extra">Laurent<br>[1] <a href="http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx</a><br>
</div><div class="gmail_extra">[2] <a href="http://www.diveintopython.net/power_of_introspection/optional_arguments.html" target="_blank">http://www.diveintopython.net/power_of_introspection/optional_arguments.html</a><br>

</div></font></span></div>
</blockquote></div><br></div>
_________________________<br> &nbsp;Racket Developers list:<br> &nbsp;<a href="http://lists.racket-lang.org/dev">http://lists.racket-lang.org/dev</a><br></blockquote></div><br></body></html>