On Mon, 23 Mar 2009 19:41:07 -0700
Mark Engelberg <[email protected]> wrote:
>
> On Mon, Mar 23, 2009 at 7:31 PM, Vincent Foley <[email protected]>
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
