On Tue, 2011-05-24 at 13:12 -0700, Jules wrote: > <rant> > > I think this issue reinforces my belief that arbitrary limits are bad. > > Re. defrecord - Should we put the onus on everyone using defrecord to > manipulate wide datasets to remember that there is an arbitrary limit > of 19 fields, or put some smarts into the defrecord macro ? > > I think we are in agreement that we should put some smarts in the > defrecord macro. > > But, hold on, why do we need smarts in the defrecord macro ? Why ? > because of an arbitrary limit in the number of params that a function > can handle. > > So, why don't we put the smarts around function > compilation/application to handle any number of params (within the > JVMs ability). This way, we can avoid having to have smarts everywhere > that a macro might expand to a function call with num params > 19. I > have direct experience of being bitten by this. > > If handling this many params means a performance hit, then, by all > means lets log a warning about it, but we should not trip up perfectly > valid code. > > </rant> > > Ah! that feels better :-)
One of the useful features of lisp programming is that limits are mostly constrained by the amount of available memory. This isn't always true but the exceptional cases are very rare. This becomes important because people generally write automatic code generator macros to support their domain specific languages. While you might never code a 20 parameter defrecord by hand it is almost certain that some macro will generate code well past that limit. I am working with code that auto-generates variables and collects them into the "let" form so there can be hundreds of them, mostly temporary variables that were gensym'ed. If the code were moved to keep the variables in a defrecord I would expect it to "just work". I'm surprised that defrecord isn't a hashed trie data structure of some sort, allowing the usual 2^32 entries. Tim Daly Literate Software d...@literatesoftware.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
