[erlang-questions] decode_packet and the philosophy of BIFs

[Sverker Eriksson]

James Hague wrote:
> I recently wrote my own HTTP header decoder, which was a fun exercise.
>  Then I realized that the erlang:decode_packet BIF does much the same
> thing, only it's in C and probably a lot faster (although my code does
> parsing of key/value pairs in URLs and some other things).
>
> On this mailing list, there's been some objection to adding too many
> BIFs, especially ones that are over-specialized, so decode_packet is a
> peculiar case.  It's misnamed: it decodes HTTP packets, yet HTTP isn't
> mentioned in the name.  It's one of the most complex BIFs, in that it
> encapsulates parsing an entire text-based format, and it takes ~20
> lines of type specifiers to describe the return value.  I'm sure
> there's an interesting story about how decode_packet managed to get
> into Erlang, especially as some other potential BIFs (like scanning
> binaries) haven't made it past the discussion stage.
>   

decode_packet() emerged from the fact that the c-code was already there, 
to implement the inet socket option {packet,Type}. It was just a matter 
of making that functionality available without having to go through a 
socket. "HTTP" is not part of its name as it also supports other 
protocols, the same as socket option {packet,Type}.

/Sverker, Erlang/OTP