On Mon, 23 Mar 2009 19:41:07 -0700 Mark Engelberg <mark.engelb...@gmail.com> wrote: > > On Mon, Mar 23, 2009 at 7:31 PM, Vincent Foley <vfo...@gmail.com> > wrote: > > More generally, is it possible that I'm just doing this whole thing > > wrong? That using vectors to represent binary fields and records > > in a declarative is just a bad idea and that I should try and > > explore lower- level alternatives? > > > > > This reminds me... I would LOVE to see in Clojure something like > Erlang's bit-packing/destructuring syntax for working with bit > manipulation in a high-level way. > > http://www.erlang.se/euc/00/bit_syntax.html >
I'm actually casually hacking on something like this right now, as I want to attempt to port a radar processing code I wrote into Clojure. (It's currently implemented in modern C++ with a functional-ish style) The WSR-88D file format is *extremely* bizarre and convoluted and requires a lot of bit-fiddling. Half or more of the current code is dedicated to converting this format into something sane. I actually hate that part of my C++ implementation the most because it's all hand-written unpacking and endianness-fixing of byte arrays which seems impossible to clean up any further. -So- .. What I actually have so far is a macro that lets you basically write Erlang bit-syntax in S-exps and it will expand into a vector that you can use as the binding list of a let form. The IP header unpacking example in Erlang's documentation looks something like this: (let (bits dgram [ip-ver 4] [hdr-len 4] svc-type [tot-len 16] [id 16] [flags 3] [frag-off 13] ttl proto [hdr-cksum 16] [src-ip 32] [dst-ip 32] [rest-dgram :binary]) 'stuff) Not shown: floats, signedness, and endianness (defaults are all the same as Erlang). It's "okay", but it looks unnatural and I don't really like doing it that way very much. The source and destination names are backwards (dgram is being destructured into ip-ver, hdr-len and so on), and the syntax hijacks the whole let form, because I don't think you can write a macro that automatically splices into its parent form. So I had been thinking of composing an email about what the likelihood of seeing extensibility API for destructuring would be. The idea being that the UI for the bit-syntax library would allow for this custom destructuring to be pervasive, look a little more conventional, and let you mix it with regular binding forms (instead of having to use an explicit let that is completely hijacked by the bit-syntax). You could of course write something that would unpack bits into a vector, and then destructure the vector on the left-hand side, but that separates the names which will be bound (on the left) from their field specifiers (passed to the macro on the right). I found this difficult to read when the specifier list gets large, so I implemented it this way so the bound names are next to their specifications (just like Erlang's). Details: the macro expands into a bunch of sequential let bindings that progressively tease apart the blob using some helper functions. I haven't actually implemented the functions that do this teasing yet because that requires me to go digging in Java API docs to see what they provide for dealing with bit-bashing, and I haven't had the inclination to do that just yet :) So, is there any chance of extensible destructuring? What would such an API look like? I have thought about it a lot, but the minutiae of doing this generally enough to be useful, but simple enough to be implementable are probably beyond my grasp. -Kyle --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---