Thoughts about namespaces and capitalization
Marcin 'Qrczak' Kowalczyk
visible is the distinction between variable and function namespaces.
While designing a language I wanted to make the binding issues simple
and beautiful. The language is dynamically typed, which implies that
the compiler doesn't have to treat names of different kinds of entities
(values, types, interfaces etc.) differently at compile time. A single
namespace is natural from the technical point of view, wnat remains are
human factors.
My language doesn't use the traditional OOP idea of making classes
namespaces for their objects. Operations are generally expressed as
standalone functions (possibly dispatched). This implies a lot of global
function names which should better be unique. Name clashes between modules
are of not fatal (you can still use them qualified by module names or
rename them during importing) but they are inconvenient.
Advocates of separate namespaces for variables and functions say that
there are many names of functions which are also good for names for local
variables, e.g. list, max, rest, size. With a single namespace one is
forced to invent names like lst, max_, maxValue, sz or len, or live with
name shadowing. I used to do this, it's a bit annoying.
OTOH a disadvantage of separate namespaces, besides aesthetical issues,
is that passing a named function as an object and applying a function
passed through a variable requires more elaborate syntax, e.g. Common
Lisp's #'func and (funcall f args).
My solution: have a single namespace, but with a convention which
distinguishes global and local names by capitalization. A case-sensitive
language is assumed of course.
Which capitalization style to use? Lowercase names are easier to read and
type than capitalized or uppercase names. In my language local names are
significantly more common than global names, especially as many common
functions are denoted by operators.
This suggests lowercase local names and capitalized global names. I mean
global names, not just global function names.
Keywords are lowercase. This fits better for several reasons:
- Most languages do this.
- When a future keyword clashes with an identifier, changing a public
global name would change the interface of a library and affect its
clients, while changing a local name is its internal problem.
- Keywords are also common.
Some purists insist that keywords should use a completely distinct
convention which prevents clashes (e.g. all uppercase or with a leading
underscore), but I haven't seen a convention which doesn't look ugly.
Most languages live with that. I currently have 27 keywords. You can
escape a name so it's not treated as a keyword and you don't have to do
that for field names in object.field syntax.
I have all uppercase type names, because most type names have a function
or constant with the same name, which is used instead of the type name
for construction of objects of that type. Record fields are lowercase.
Sometimes a function sets up a namespace for lots of local functions.
In such case I break the convention and capitalize names of local
functions as if they were global. Sorry about that, nobody is perfect -
it just looks better :-)
CapitalizeEachWord and use camelCase or separate_words_by_underscores?
I believe in no underscores (except all-uppercase names). Advocates of
underscores say that it's easier to read long names written with such
visual spacing, they like to invent easy_to_read_examples_with_many_words
and contrast them with harderToReadExamplesWithManyWords.
My claim is that it's true but it doesn't matter. It's more important
to recognize the name as a single entity than to read it as a prose.
In reality very few names are composed of so many words anyway.
My syntax very often yields identifiers separated by a space and usually
uses positional arguments. An underscore would be similar to a space,
which has a different meaning, and it would be harder to see how many
arguments there are. I used to use underscores but changed my mind.
With my syntax identifiers without underscores make the whole program
more readable.
A functional language encourages long expressions and generally requires
to invent more distinct names than an imperative language. This makes
shorter names more attractive, they make easier to fit code horizontally.
Using capitalization you can encode more in less space.
And last but not least, with the convention of capitalizing global names
they look better than camelCase, because all words are capitalized the
same way. Multiword local names (which use camelCase) are rarer.
Now I am happy with lexical conventions and I go back to finishing the
compiler. I hope someone will find my thoughts valuable.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
cr88192
"Marcin 'Qrczak' Kowalczyk" <qrc...@knm.org.pl> wrote in message
news:pan.2003.10.28....@knm.org.pl...
>
> Now I am happy with lexical conventions and I go back to finishing the
> compiler. I hope someone will find my thoughts valuable.
>
I agree with many of your comments in this case. sadly, my recent os effort
leads to much less lang related effort... too bad I can't have all projects
at once (though previously my os had used my lang, this is no longer the
case).
depending on the definition of "keyword" (I am assuming you mean in the lisp
sense), different meanings can be implied (ok, this was vague...).
in my sense I had keywords and had used a following colon ':'. my keywords
thus looked like 'a: group: of: keywords:'. I also supported prefix colons
':a :different :style'. I had also given them slightly different behavior as
well, eg: in some cases a keyword with a postfix colon would match a symbol,
but this is not the case with prefix colons:
(matchv? kw: 'kw) => #t
(matchv? :kw 'kw) => #f
also:
(matchv? :kw kw:) => #f
in my case, since my lang was a mutated form of scheme I was not as free to
choose, say, case sensitivity or the naming convention. using a different
convention would look out of place, and mixing conventions would look bad.
in my c code I most commonly use the CapitalizeFirstLetter convention for
functions, along with a prefix, so my names look like:
SAMN_RestWordsWithWordsCapped
SAMN: Some Acronym Module Name (aka: a nemonic for what code I am working
on).
variable names typically are similar, except that they are all lower case
and seperated with underscores.
similar often goes for static functions.
macros are typically all upper case, only sometimes using underscores as a
seperator...
inline functions often also use this notation, but with a lowercase 'i'
stuck on the end.
static inline int MYINLINEi()
...
other times they are written with an all lower case name.
only bits of this map to other languages, usually I end up with a different
style for each programming language I write in, but often they are
comprable...
misc:
I wrote more of a compiler for my lang. it compiles to c, and this time
should get ok performance (though at present there is neither tail call
optimization nor continuations...).
a problem right now:
there is a bit of an internal difference between my old runtime and the code
generated by my compiler (a convention I would rather not use for general
code/a c side interface). this was requiring a bit of stubbing so far.
a possibility would be a tool that would write out a lot of stub code, or
maybe including compiler command/special forms that generate the stub code
for me or alter the compilation of code dealing with external functions
(this could be faster but would limit any real ability to assign/pass around
externally defined functions...).
hell, maybe a stubber could also handle mashalling to/from basic c types as
well...
in large amounts this stub code could become expensive. another possibility
would be to have "modules" which could contain lots of stub code, but I
would have to write the modules bit...
Marcin 'Qrczak' Kowalczyk
> depending on the definition of "keyword" (I am assuming you mean in the
> lisp sense),
No, I meant builtin syntax words like "def", "if", "let" and "self".
I also have symbols (isomorphic to strings):
:sym
and symbol/value pairs:
sym: value
which is equivalent to:
:sym, value
but doesn't have to be paranthesized so often and is used to emulate
keyword arguments. Symbols don't belong to any namespace.
> only bits of this map to other languages, usually I end up with a different
> style for each programming language I write in, but often they are
> comprable...
I'm trying to match the common conventions for the given language.
C doesn't have a universally accepted convention for function names
(the standard library uses lowercase without separators which doesn't
scale to longer names), but most people seem to use lowercase separated
by underscores.
cr88192
> On Tue, 28 Oct 2003 18:04:02 -0800, cr88192 wrote:
>
> > depending on the definition of "keyword" (I am assuming you mean in the
> > lisp sense),
>
> No, I meant builtin syntax words like "def", "if", "let" and "self".
>
my language does everything (in all syntax's) using generic forms and
(optionally for the most part) syntactic characters.
in the case of self, self was actually a dynamic variable.
usually I refer to these as "reserved words".
> I also have symbols (isomorphic to strings):
> :sym
> and symbol/value pairs:
> sym: value
> which is equivalent to:
> :sym, value
> but doesn't have to be paranthesized so often and is used to emulate
> keyword arguments. Symbols don't belong to any namespace.
>
yes, similarly I dropped the "namespace" concept (again, assuming you mean
in the cl sense).
quite possibly though I will re-add modules (with my recent delves into
compiled code). in this case ':' will probably have special meaning when
embedded in a name ('foo:bar', the variable bar in the module foo).
quite possibly this will be different between symbols used in code and those
quoted, eg:
(foo:bar 1 2) ;will call module foo, variable bar, with 1 2;
'foo:bar ;is a single symbol, "foo:bar".
':' will not be '.', where '.' actually causes a syntactic transformation on
the name:
x.y.z => ((x 'y) 'z).
similar occures with quote, but I am not sure if this is desirable:
'x.y.z => '((x 'y) 'z).
my lang did not have "keyword arguments" in the cl sense, instead it was
necessary to parse the args list.
> > only bits of this map to other languages, usually I end up with a
different
> > style for each programming language I write in, but often they are
> > comprable...
>
> I'm trying to match the common conventions for the given language.
> C doesn't have a universally accepted convention for function names
> (the standard library uses lowercase without separators which doesn't
> scale to longer names), but most people seem to use lowercase separated
> by underscores.
>
yes, for me it depends...
I think it was that when I was younger I spent a fair amount of time messing
with id software's source (wolfenstien, doom, quake, ...), so I think I
picked up at least some amount of their style...
as time goes on my style shifts, so now it looks less like id's than it once
did...
I am unsure, I would have to look again to be more sure...