p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments but perhaps 'new' can play the role for both:
(new fisht #:name "Nemo" #:weight 700) and (new fisht% #:name "Nemo" #:weight 700) might work. On Jun 17, 2013, at 10:52 AM, Laurent wrote: > Actually I realize I'd like something exactly like `instantiate'. > 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: > > (define nemo (fish% "Nemo" #:age 3)) ; instantiates `fish%' > > Of course this could be extended to structs. > > This would harmonize different calling mechanisms, as well as being more > flexible. > Wouldn't that be nice? > > Laurent > > > On Fri, Jun 7, 2013 at 8:12 AM, Laurent <laurent.ors...@gmail.com> wrote: > > > > On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: > > I've always wondered why the syntax of keywords implied two elements: the > > #:keyword and the identifier. > > I find that quite heavy for procedure headers, and most of the time I use > > the same symbol for the identifier and the keyword (and when I don't it's > > because I'm simply lazy and use a shorter identifier). > > > > Is there a rationale somewhere for that? > > The rationale is to make function definitions have the same shape as > function calls. > > I see what you mean, though I wouldn't make a strong case of it (maybe I'm > missing something). > > From time to time, I really feel frustrated by the current function header > style. > > What I'd really like, for the sake of flexibility / ease of use, is to > have no explicit keyword argument, but all arguments are implicit ones, so > that you can call a function by mixing by position and by name as you like, > without having specified so in the function's header. > (Visual Basic[1] and Python[2] do something along these lines.) > > For example: > (define (foo x y [z 3] [t 4]) ....) > > (foo 1 2 5) > (foo #:z 5 #:y 1 #:x 2) > (foo 1 #:t 6 #:y 3) > > (foo #:x 3) > Error: missing mandatory argument `y' > > (apply/kw f 2 #:y 3 '(5) '((t . 3))) > > In particular, one would then not have to worry about the order of the > optional arguments in the function definition. > > Headers would be also smaller, easier to read, and easier to write. > > Pushing a bit further: > (define (foo x y . rest) ....) > would not accept keywords different from #:x and #:y, but > (define (foo x y . rest-by-pos . rest-by-name) ....) > would receive a list of positional argument values, and a dictionary of > names and values, even if these names are not x or y. > > Laurent > [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx > [2] > http://www.diveintopython.net/power_of_introspection/optional_arguments.html > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
