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

[Sean Conner <sean@...>]

It was thus said that the Great François Perrad once stated:
> 2017-05-26 21:03 GMT+02:00 Aaron B. <aaron@zadzmo.org>:
> 
> > On Fri, 26 May 2017 17:32:49 +0200
> > François Perrad <francois.perrad@gadz.org> wrote:
> >
> > >     printf("x = %d  y = %d", 10, 20);                           -- C
> > >     string.format("x = %d  y = %d", 10, 20)                     -- Lua
> > 5.0
> > >     ("x = %d  y = %d"):format(10, 20)                           -- Lua
> > 5.1
> > >     cout << "x = " << 10 << "  y = " << 20;                     -- C++
> > >     string.buffer():put'x = ':put(10):put'  y = ':put(20)       --
> > proposal
> >
> > The C/Lua 5.0/Lua 5.1 way looks a lot more readable to me, compared to
> > the C++/proposal method.
> >
> > The reason being, with the format string, in a glance I can see what
> > the output will look like. With the stream, I have to put all the pieces
> > together in my mind first.
> >
> >
> > --
> > Aaron B. <aaron@zadzmo.org>
> >
> >
> 
> Well, at this time, the feedbacks seem clear : everybody is happy with
> minilanguages.
> 
> As seasoned C developer, I know (and I daily use) the `sprintf` formating,
> so I am biased.
> But the pack/unpack minilanguage is not obviously readable.
> And same thing with `os.date` which uses the C `strftime` minilanguage.

  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 agree with the strftime minilanguage---I have to look that one up every
single time I use it.  

> An implementation based on a minilanguage doesn't allow user extension, for
> example, you cannot add a "%Q" option to `string.format` in pure Lua.

  That doesn't *have* to be the case though.  A minilanguage *could* be
designed to allow user defined extensions, but the problem there is mixing
code that install their own extensions to the same minilanguage---there
could be conflicts.  And someone maintaining the code will have to know
where to find the code that defines the extensions.

  -spc