On Fri, Nov 12, 2010 at 5:20 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Fri, Nov 12, 2010 at 11:15 AM, John Zabroski <[email protected]>wrote: > >> >> >> On Thu, Nov 11, 2010 at 7:44 PM, Jonathan S. Shapiro <[email protected]>wrote: >> >>> Other than bit sets and enumerations, what **commonly used** types want >>> to introduce new, named literals? >>> >>> [and unions, for constructors] >>> >>> shap >>> >>> >> 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? > > > Jonathan > 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 [1], and he basically countered by saying I was being unfair [2]. 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 [3]. As I argued in [1], 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 [2], he counters by saying [3] 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 [3]. 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. [1] http://groups.google.com/group/golang-nuts/msg/f630b3ab1bee4201 [2] http://groups.google.com/group/golang-nuts/msg/282db7f37b03ebc1 [3] Russ Cox's code for blitting a byte stream into a data format http://groups.google.com/group/golang-nuts/msg/f57c9644960897fc
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
