Re: [PROPOSAL 5.4] alternate way of format/pack/unpack (in the string library)

[Sean Conner <sean@...>]

It was thus said that the Great Pierre Chapuis once stated:
> May 26, 2017 11:55 PM, "Sean Conner" <sean@conman.org> wrote:
> 
> > I don't find the pack/unpack minilanguage all that bad, per se. Lowercase
> > letters are signed quantities, uppercase unsigned and there's some mneumonic
> > meaning to the letters used. But it can get silly (sample from an SMPP
> > parser):
> > 
> > result.service_type,
> > result.source.addr_ton,
> > result.source.addr_npi,
> > result.source.addr,
> > result.dest.addr_ton,
> > result.dest.addr_npi,
> > result.dest.addr,
> > result.esm_class,
> > result.protocol_id,
> > result.prority,
> > result.schedule_time,
> > result.validity_period,
> > result.registered_delivery,
> > result.replace_if_present,
> > result.data_coding,
> > result.sm_default_msg_id,
> > result.message =
> > string.unpack(">z I1 I1 z I1 I1 z I1 I1 I1 z z I1 I1 I1 I1 s1",blob,13)
> > 
> > It was hard to debug, and the obvious solution:
> > 
> > result.service_type,pos = string.unpack(">z",blob,pos)
> > result.source.addr_ton,pos = string.unpack(">I1",blob,pos)
> > result.source.addr_npi,pos = string.unpack(">I1",blob,pos)
> > --- and so on
> > 
> > just *feels* a lot slower to me. One could try to create another
> > minilanguage for this, and I've tried, but I haven't created one that I
> > like (for me, the *same* language should create both encoder and decoder).
> 

> I really liked the idea behind Ignacio Burgueño's solution for that issue
> in his ZX Spectrum emulator [1].

  Cute, but elsewhere [2] he did it more elegantly in 1/14 the number of
lines, and it's functionally equivalent (and just as clear from the
formatting).

  -spc

> [1] https://github.com/ignacio/luagleck/blob/bd342a920bc67de48764327c9e881d3e15bc3a4d/file_format/sna.lua#L25-L67

[2] https://github.com/ignacio/luagleck/blob/bd342a920bc67de48764327c9e881d3e15bc3a4d/file_format/z80.lua#L237-L239