Þ   briarpig  » names

     Scheme, Smalltalk, and Python (see λσπ) apis needn't use names like those described here, and generally won't in conventional versions of those languages. But I might add libraries to them all using þ style names.

acronyms

     Basic þ names are acronyms, mostly lowercase, with one letter per word. Of course, this would be perfectly incomprehensible unless you knew which words might be meant. So in þ the basic set of words is everything. It's not a large set of words, making it feasible.

namespaces

     Two kinds of name qualification are used in þ: a old-style letter prefix, and a new-style C++ namespace. The namespace, which is currently mu, is subject to change and doesn't matter†. The single letter prefix on global symbol names is y (for several reasons: symbol, yggdrasil, and substitution† of y glyphs for the Old English th ligature). Native scalar types do not start with y — instead they suffix the number of bits in the size (u8: unsigned char, i16: short, r32: float, etc).

hungarian

     (Some folks think þ's names are Hungarian notation, which is almost right, if you mean apps and not system Hungarian. I'm unfamiliar with it and don't care to make useless comparisons, so I've little else to say about Hungarian. Please remember the correct name for þ's naming scheme is thorn notation. But if you wanted to be funny you could call it Gaelic notation.)

disambiguation

     Some letters can mean more than one word, but rarely more than two in þ's lexicon, and context makes it easy to disambiguate (max and mutex). Some names have no more letters in them than necessary to disambiguate from other names, avoiding any pursuit of total disclosure using names alone. With several letters, you'll need to look it up anyway.

concatenation

     Many class names merely concatenate several single letter names. For example, yrqp means reverse queue pointer, and means nearly list::reverse_iterator. The letter p at the end of a class name almost always means pointer, which means it's an iterator. Similarly, yfoz means file outstream slice, except trailing z is always used to mean slice (a ref to a sliced object, plus a position offset and length).

prefixes

     Most names within a class scope (methods, vars, nested classes) have a short prefix based on the class name's last letter. For example, a map class whose name has m as the last letter will use the following prefixes. Methods: m (mfind(), merase()), vars: m_ (m_foo, m_bar), nested classes: uppercase M (class Mfoo { ... }). Classes inheriting multiply can thus reveal which base class defined inherited symbols.

uppercase

     Beyond nested classes, uppercase is used only for important or complex objects, to distinguish them from simpler lowercased names. For example, M: virtual machine, H: heap, P: page, and B: book. (A book is a mega page.) Lowercase versions are m: map, h: handle (smartref), p: pointer, and b: buf or box (in gc memory).

     (Class yPBH is a Page Book Heap, and allocates refcounted pages and books at page-aligned and book-aligned memory addresses. For example, Page node class yPn is a subclass of the refcounted node base class yn. Method yPn::npage() returns yP*, the pointer to a page-aligned address, which comes from a member var named n_P.)

templates

     Most class names ending with t are templates. (The single exception is yt — the 4-byte tag preceding each box in gc memory.) Class ymt<> resembles std::map<> (except it's a hashmap, not a tree), and yqt<> resembles std::list<>, except the þ versions are concerned with allocation using pages and books (and are little tested as yet). Collections in þ aim for entropy free patterns of new and delete, by avoiding external fragmentation at the cost of internal fragmentation. Pages and books are interchangeable.

endings

     The shorter a class name, the easier it is to see a difference from another class name with similar words in the name. If most names are just a few letters long, one letter difference is fairly easy to see, especially when it's the last letter, and matters most. If names are structured as adjective, adjective, adjective, noun, then the ending is what it is. (Note nouns become adjectives when they describe another noun, especially when refining kind. ¹)

     Choose one of these demos for sample code and related docs, developed together to motivate þ C++ code for this purpose.

     mu: toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile

     thorn: todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, meter, list, iter, ctype

     The new mu menu links future toy language pages. Many demos are stubs; see todo for a thorn demo guide, or toy for mu updates. Also see names for an overview of naming schemes.

     Names really matter to software developers. Even whitespace matters to developers (who cannot stop discussing the one true tab style). Every software project has a standard coding style for naming things. Exposure to a new style can be disagreeable and even alarming.

work

     Obviously, at work I write code in a style much like everyone else's at work, except with the odd extra namespace thrown in here and there. (And I write comments — lots of comments — which isn't the norm at all, but everyone likes this difference.)

     At work and in large projects, one goal is to make everything fit; part of this is writing in common style as much as possible. So þ's aggressively concise style would never be used in a workplace, unless (by some miracle) þ was embraced.

nih

     Though þ happens to use C++, þ is not a good C++ citizen — parts of þ resemble an exercise in NIH (not invented here) because it avoids normal C++ apis, and replaces many standard utils. Few symbols outside þ are used, except as a way of testing conformance to expected behavior.

     Resulting isolation lets a developer completely instrument þ's runtime for exhaustive analysis. This is intentional, and further aims to let þ vary memory management disciplines from those in C++ standard libs, for a better base to support dynamic languages on top. It's control (cf insight†), not re-invention.

renaming

     A future part of the þ library might include a C++ to C++ translator for renaming symbols. Even without short names, this seems a good idea, to generate variants of þ with new natures. So that's part of a vague plan. However, this site only documents short names with care.

apology

     At left we introduce current styles used to name classes and variables in the þ runtime library. Pages under this one can bore into further detail. But first an explanation might be in order — and perhaps an apology to any professional coders who feel a growing twinge of horror at first sight of þ's terribly brief names.

origins

     What prompted þ's weirdly short names? It was an essay by Paul Graham. In Arc at 3 weeks, he mentioned (quoted here†) some designers (eg briarpig) fall in the short-name school, feeling more spartan is better.

     Graham's remarks started a train of thought exploring this question: What were the shortest feasible symbol names one could use in C++? What if you were willing to ignore convention altogether, and aimed for extreme brevity. What would the limit be? Would it be garbage?

     Short names were an experiment that seemed likely to fail due to excessive use of logical positivism given far too few categories for organizing class traits. But the core of þ has only a few things it wants to consider, mostly related to memory management, which helps.

strings

     I started thinking about it seriously a few years ago, after beginning a new job, where I had to memorize new names for a slew of old ideas, like a new "string" class which obviously intended to be some kind of string, but what about details? (cf Bray†.) Class names are at best a clue about life in detail, which still have to be studied the hard way (global search).

     Names tend to do little more than hint, and convey less than a single line comment of twelve words. I usually get more info about a class from a first line of good docs than I do from it's name. If you start to think of class names as arbitrary things to memorize, maybe it would be more productive to make them easy to memorize. Such as short.