[bitc-dev] Types that introduce new literals
johnzabroski at gmail.com
Fri Nov 12 17:03:47 PST 2010
On Fri, Nov 12, 2010 at 5:20 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
> On Fri, Nov 12, 2010 at 11:15 AM, John Zabroski <johnzabroski at gmail.com>wrote:
>> On Thu, Nov 11, 2010 at 7:44 PM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
>>> Other than bit sets and enumerations, what **commonly used** types want
>>> to introduce new, named literals?
>>> [and unions, for constructors]
>> If you are asking about programming languages in general, then "syntax for
>> hashes" has to be up there....
> That's not quite what I meant.
> Enumerations are one example - the enumerands are new bindings.
> Bit sets having named elements are another - a series of bindings gets
> introduced for the individual bit names.
> Unions introduce leg constructors.
> What other commonly used constructs introduce multiple named elements in a
> single declaration in that sort of way?
In that case, some bit sets can be conditional. For example, a packet
header might indicate what version of a protocol is being used, and based on
the protocol, a different set of bindings get introduced for the individual
bit names. A higher-order byte in a byte stream can also therefore indicate
the blitting format for a data stream.
Leg constructors can also have guards.
Look at it this way. Most low-level high-level languages allow the
programmer to come up with *some* scheme to abuse the static production
rules of the language and write something somewhat auditable, such that any
old Joe can figure out what the program does. I argued with Go developer
Russ Cox about this on the Golang-nuts mailing list , and he basically
countered by saying I was being unfair . Russ presented an example of
how "easy" it is to write Go code that can blit some data structures; all
the developer has to know is the idioms Russ uses in his code . As I
argued in , his example breaks down insofar as the "gee, this looks easy
and great!" metric once you start adding use cases like protocol versioning,
feature detection, and other dynamic, intentional scenarios where the
situation-at-hand has the final say. In , he counters by saying  is
real world code and implies that I should not call real world code a naive
example. I think he simply misunderstood my use of the word "naive" here.
I meant that the example chosen didn't show how well the system scaled for
auditability as the programming problem became more complex. Real world
systems often have legacy protocols with a myriad of data formats to
support, and they often have to discover and work with those data formats
dynamically. (I think I encountered at least 5 errors today due to
improperly written software with these requirements handled insufficiently.)
The BitC 0.11 documentation refers to bitfields as static representations,
by the way, and does not discuss the use cases I am referring to. The
current docs imply static, extensional scenarios only, similar to the
example Russ Cox provides . I haven't tried it yet, but I am assuming
the way BitC expects developers to accomplish these sorts of dynamic,
intentional scenarios is through the use of type functions and aggregate
data types like bitfields.
By the way, I like Cox's example, but feel it is too simple to illustrate
the range of idioms I've seen in C, C++ and Ada code over the years for
these low-level manipulations.
 Russ Cox's code for blitting a byte stream into a data format
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev