Racket has linguistic support for keyword arguments, which address
many of the issues you raised:
http://docs.racket-lang.org/guide/keywords.html

Would this help in your case?

Additional background: http://www.cs.utah.edu/plt/publications/scheme09-fb.pdf

On Mon, Jul 6, 2015 at 10:56 AM, John Carmack <jo...@oculus.com> wrote:
> A primary goal of the scripting work is that it should be easy to do easy
> things.  You shouldn’t have to specify all the options if you just want to
> play a sound or show a picture, but you should still be able to get at them
> when you need them.
>
>
>
> For the case of a sound effect, all of the following data may be specified:
>
>
>
> Wav file – URI to a .wav file with audio samples.
>
> Volume – Scale factor for the wav samples.
>
> Position – 3D point for HRTF spatialized audio processing.
>
> Looping – Flag to cause the wav file to loop continuously.
>
> Name – An identifier to allow the parameters on a playing sound to be
> updated later.
>
> Time – Absolute time for the sound to start, necessary for synced background
> audio in drop-in multiplayer servers and glitch free transitioning between
> wav files.
>
>
>
> There are four broad strategies for exposing all that.
>
>
>
> Multiple functions for different sets of parameters:
>
> (+sound wav-string)
>
> (+sound-positioned Wav-string position-vec3)
>
> (+named-sound wav-string position-vec3 sound-name)
>
> (+sound-update sound-name new-position-vec3)
>
>
>
> This has a combinatorial explosion problem.
>
>
>
> Optional parameter count with implicit type by position, C++ style:
>
> (+sound wav-string position-vec3 name-int volume-float looping-bool
> time-float)
>
>
>
> Need to define special values for parameters that are essentially skipped –
> POSITION_NONE, NAME_NONE, etc, since it is possible to want to set later
> values without all the preceding ones.  Not very self-documenting, and not
> feasible for large numbers of options like GPU state.
>
>
>
> Keyword delimited parameters, command line parsing style:
>
> (+sound ‘wav wav-string ‘position position-vec3 ‘name name-int ‘volume
> volume-float ‘looping looping-bool ‘time time-float)
>
>
>
> A typo in an option symbol name will not be detected at compile time if done
> as a function, but I guess that is a good argument for a macro.
>
>
>
> Option functions:
>
> (+sound (opt-wav wav-string) (opt-position position-vec3) (opt-name
> name-int) (opt-volume volume-float) (opt-looping looping-bool) (opt-time
> time-float))
>
>
>
> Simple to do transformations or validation on the inputs, but the most
> verbose.
>
> Bad option names will be detected at compile time, but you could still
> compile, say, graphics options into a sound command, which would have been
> detected with the keyword delimited parameters.
>
>
>
> In some cases, parameters can be inferred by type.  For sounds, a parameter
> that is a string is the wav, a float is the volume, a bool is looping, a
> vec3 is position, an int is name.  That is sheer luck – other commands would
> very likely have multiple parameters with common types, and even here there
> would be an ambiguity with time.  Still, it would be possible to go
> type-system-happy and explicitly have types for everything.  I suppose that
> would syntactically degenerate to option functions.
>
>
>
> It is tempting to use flags that are just signaled by their presence – just
> add ‘looping instead of ‘looping #t or (looping #t), but that can be awkward
> when the state of a flag is programmatically evaluated.
>
>
>
> Currently I am using a hybrid form, where the first parameter is an implicit
> type (and second parameter for gfx commands), and all following parameters
> are evaluated and appended as options.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to