Is enum a suitable way to implement a "local define?"

[BartC]

BartC seems to be here to discuss the features of some other language than
C,
which he is working on, with the evident side goal of avoiding learning C
as
much as possible while proposing improvements to it.

No concrete, complete spec of the other language is ever given, so it is
impossible to discuss properly; this aspect keeps the discussions
quasi-topical, allowing the focus to stay on BartC's years-long learning
disability with regard to C.

BartC is somewhat like a higher-level Bill Cunningham.
Thanks.

(And note how the initials of both characters are B.C.!)

That's very interesting.

There are strong parallels in the trolling theme: a person who is toying
with
some projects that don't seem to advance from year to year (as far as we
can
glean their status from the fleeting descriptions), and who exhibits
anterograde amnesia with regard to absorbing new material from other
posters.

I wrote my first compiler (a very simple one for a machine-oriented language
for the PDP10) in 1980 while a student.

I've been designing my own languages and creating my own compilers, all from
scratch, since 1981.

Those early static languages had paralleled much of C, and were for the same
sorts of purposes, but used entirely different syntax. I switched to using
C's runtime since around 1997 I think.

I've been dependent on an actual C compiler since 2012, in a project which
was a thin syntax wrapper around C. A new project completed earlier this
year which was an independent language, but targets high-level C code. (I am
upgrading that again so that it generates native code directly, because C is
giving me too many headaches.)

So as a designer of a set of languages with similar aims to C, and as a
compiler writer, and also now as user of the language (for a brief period
when I had to write it, and now when I have to generate it), I think I am
entitled to my opinions, and also that I qualified to some extent in giving
constructive criticisms.

I do find some of C's decisions exasperating (it's type syntax, the lack of
a named constant feature (one of the simplest you could think of!), its
idiosyncratic for-statement etc etc), because I know how easy it would have
been to implement them properly.

As for my projects: I have two language projects: "X" (not its real name), a
dynamic language, with a compiler written in X. It has an interpreter "I"
now written in Y, a static language. Y's compiler is written in X, the
output at present is raw C. It has some help (with interfacing) from a
hybrid language B (its real name), which is a wrapper around C, and whose
output is also raw C.

Confused? You should be! Anyway these languages and compiler projects really
exist, and they work.

Why do I still post in comp.lang.c? I think that as a C 'outsider' I can
offer a somewhat different, perhaps irreverent point of view compared with
the the usual guys. Look at my first post in this thread, and tell me how
much of that was about my own stuff.

 

[glen herrmannsfeldt]

(snip)

ANSI Common Lisp uses "variable", and nonchalantly introduces the
oxymoron "constant variable" as a normative term in its glossary:

constant variable n. a variable, the value of which can never
change; that is, a keyword or a named constant.
``The symbols t, nil, :direction, and most-positive-fixnum
are constant variables.''

Cringe-inducing abuse of English. As adjectives, "constant"
and "variable" are diametric opposites. To be constant is
not to vary.

I suppose, but in the algebra statement:

X=2

do you call X a variable? Seems to me that you treat is as a variable
in algebraic operations, but then consider it to have the value 2.

If you do that, someone could come along later, erase the 2, write
in 3, and the rest of the page would be correct, except possibly
that last line where the 2 is plugged in.

In computers, a more important distinction is whether memory
is allocated to store it in. A Fortran PARAMETER is normally not
considered a variable, and normally not in allocated memory.

In Java, static final variables can't be changed, but one could go
edit the file where the value was defined and put in a different one.
When declared in the same class, the compiler can optimize them just
like constants, and process constant expressions accordingly.
From a different class, I think the compiler can't do that.

There is a story from someone with an atomic clock that is good
to 1 part in 1e18. There was a comment that it wouldn't lose a
second over the age of the universe, where someone then commented
that they didn't think the plastic on the wires would last that long.

When deciding that something is constant, you have to give the
time scale for it being constant.


-- glen

 

[Keith Thompson]

Correction: the standard does use the term, but it doesn't define it.

It's interesting to find out that C never defines the term.
I thought that C defined it in an analogous way to how C++ defines it:

"A /variable/ is introduced by the declaration ((of a reference
other than a non-static data member or)) of an object.
The variable’s name denotes the ((reference or)) object."

excluding the irrelevant parts about references (marked with (( )) by me),
of course. So a key feature of a variable would be a named, declared thing.

I've seen that definition before. The problem with it is that it
makes a couple of statements about variables without actually saying
what a variable *is*. Perhaps the author(s) thought it was obvious.

The obvious meaning would be that the object *is* a "variable",
but it doesn't actually say so. A "variable" could also be some
abstract thingie that isn't the object, but whose name denotes
the object. It could even be a compile-time symbol table entry.

If I have an object declared in a recursive function, and there are
currently two running instances of the function, I have two object
with the same name. Is that one "variable" or two? How is either
answer supported by that definition?

Getting back to C (which doesn't define the term), there are plenty
of contexts where the word "variable" can be used without ambiguity.
If you say that `int x = 42;` defines a variable whose name is "x",
whose type is int, and whose initial value is 42, I have no problem
with that.

The problem is when it's used where the distinction between
declarations and objects or between const and non-const objects,
or among named objects, subobjects, and allocated objects, actually
matters. In such contexts, I think it's best to stick as closely
possible to the terms defined by the standard, and to use them with
their standard-defined meanings.

[...]

 

[James Kuyper]

On 04/10/2014 03:18 PM, BartC wrote:
....

So as a designer of a set of languages with similar aims to C, and as a
compiler writer, and also now as user of the language (for a brief period
when I had to write it, and now when I have to generate it), I think I am
entitled to my opinions, and also that I qualified to some extent in giving
constructive criticisms.

Your lack of knowledge of and experience with C limits the extent to
which you are so qualified. When you just recently became aware of a
feature of C because it caused your code generator to produce
malfunctioning code, it's a little early to criticize that feature (I'm
not referring to any specific feature here, but rather to any one of
several different features you've criticized in the past). It's
understandable why you would want to blame the design of C for not being
what you would consider appropriate, but the criticism would be better
received if it had been the result of spending many years working within
that design, and having a corresponding awareness of it's costs and
benefits.

Why do I still post in comp.lang.c? I think that as a C 'outsider' I can
offer a somewhat different, perhaps irreverent point of view compared with
the the usual guys. ...

Your outsider point of view would be of greater interest if it were
better informed. Irreverence isn't a problem in itself, none of us here
worship at the altar of the almighty standard, claims by trolls to the
contrary notwithstanding. But criticisms based upon a solid understand
of what the standard actually says, and informed by a fair amount of
experience working with the feature, would be much better received.

 

[James Kuyper]

On 04/10/2014 03:36 PM, glen herrmannsfeldt wrote:
....

There is a story from someone with an atomic clock that is good
to 1 part in 1e18. There was a comment that it wouldn't lose a
second over the age of the universe, where someone then commented
that they didn't think the plastic on the wires would last that long.

The big official time keepers actually use multiple atomic clocks,
allowing them to take one out of service for maintenance (such as
replacing the wires), and re-syncing it with the others when the
maintenance is complete. I find it amazing that they can re-sync it with
sufficient precision, but apparently they can do so.

 

[James Kuyper]

Correction: the standard does use the term, but it doesn't define it.


I've seen that definition before. The problem with it is that it
makes a couple of statements about variables without actually saying
what a variable *is*. Perhaps the author(s) thought it was obvious.

True: but it uses the ISO convention of italicizing "variable" to
identify that clause, despite it's defects, as the official definition
of "variable".

The obvious meaning would be that the object *is* a "variable",
but it doesn't actually say so. A "variable" could also be some
abstract thingie that isn't the object, but whose name denotes
the object. It could even be a compile-time symbol table entry.

I don't think that's consistent with the sentence "The variable's name
denotes the object." If it's the variable's name, how can the name
denote anything other than the variable? To put it another way, if the
name denotes the object, and if the variable is something other than the
object, how does the name qualify as being the name of that variable?

 

[glen herrmannsfeldt]

On 04/10/2014 03:36 PM, glen herrmannsfeldt wrote:

The big official time keepers actually use multiple atomic clocks,
allowing them to take one out of service for maintenance (such as
replacing the wires), and re-syncing it with the others when the
maintenance is complete. I find it amazing that they can re-sync it with
sufficient precision, but apparently they can do so.

But the physical clock, even if you do that, won't last 1e18s.

By the way, the clock is good enough to measure the general
relativistic effect from the change in gravitational field if
you lift it up 0.3m (one foot for those using that system).

-- glen



-- glen

 

[Kenny McCormack]

Your outsider point of view pisses me off and makes me feel small and
unmasculine. That's why I take every opportunity to belittle you here in
this forum. Heresy to the one true standard is and always will be dealt
with severely in this forum - as we continue to worship at the altar of
the almighty standard. Therefore, you'd best keep your criticisms to
yourself and not bother usa (your betters) or try to contradict our
interpretation of what the standard actually says. I hope this better
informs you of what it means to have experience working with a feature.
Maybe in future, you will be much better received. I am hopeful that
there may be hope for you yet.

Sad, isn't it?

 

[James Kuyper]

But the physical clock, even if you do that, won't last 1e18s.

Replacing the entire physical clock is just an extreme form of
"maintenance", and can be dealt with in the same fashion.

 

[Keith Thompson]

True: but it uses the ISO convention of italicizing "variable" to
identify that clause, despite it's defects, as the official definition
of "variable".

Which would be fine if it were actually a definition.

I don't think that's consistent with the sentence "The variable's name
denotes the object." If it's the variable's name, how can the name
denote anything other than the variable? To put it another way, if the
name denotes the object, and if the variable is something other than the
object, how does the name qualify as being the name of that variable?

Hmm. If the statement "the FOO'S name is BAR" is logically
equivalent to "the name BAR denotes the FOO", then I see your point.

I'm thinking of the possibility that a "variable" is an abstract
entity that has an attribute called its "name", and that that name
*when used in a program* denotes the object.

If the intent is that the variable is the object, then the definition
should just say so. As it stands, the wording "A variable is
introduced by the declaration ... of an object" implies, at least
to me, that the variable and the object are two different things.

I think I recall someone claiming that a "variable" is the *name*
of an object, not the object itself -- but the phrase "The variable's
name" is inconsistent with that.

Summary: IMHO we all know what a variable is in some cases, we'll
probably never all agree on what is or is not a variable in all cases,
and the C++ standard does a poor job of defining the term.

 

[James Kuyper]

Which would be fine if it were actually a definition.

Agreed. It could certainly be improved.

....

Hmm. If the statement "the FOO'S name is BAR" is logically
equivalent to "the name BAR denotes the FOO", then I see your point.

Yes, that's what I'm saying. The argument isn't quite airtight, but it
seems good enough to me.

....

Summary: IMHO we all know what a variable is in some cases, we'll
probably never all agree on what is or is not a variable in all cases,
and the C++ standard does a poor job of defining the term.

While reviewing the usage of "variable" in the C standard, I came across
several places where I'm fairly certain that what it said was intended
to apply to unnamed objects as well as named ones - mostly in the
context of text that is new in C2011. Either "variable" should be
replaced by "object" in those cases, or C should formally adopt a
definition for "variable" that's inconsistent with the C++ definition. I
don't think we can afford to leave that issue open.

 

[Kaz Kylheku]

I wrote my first compiler (a very simple one for a machine-oriented language
for the PDP10) in 1980 while a student.

I've been designing my own languages and creating my own compilers, all from
scratch, since 1981.

So you should be able to chew up a language specification and spit it out.

 

[Keith Thompson]

Agreed. It could certainly be improved.

...

Yes, that's what I'm saying. The argument isn't quite airtight, but it
seems good enough to me.

...

While reviewing the usage of "variable" in the C standard, I came across
several places where I'm fairly certain that what it said was intended
to apply to unnamed objects as well as named ones - mostly in the
context of text that is new in C2011. Either "variable" should be
replaced by "object" in those cases, or C should formally adopt a
definition for "variable" that's inconsistent with the C++ definition. I
don't think we can afford to leave that issue open.

Looking at the uses of the word "variable" in the C++ standard, I see at
least one that clearly implies that a "variable" is, or at the very
least can be, an object. C++11 3.2 (One definition rule), paragraph 2:

A variable whose name appears as a potentially-evaluated
expression is *odr-used* unless it is an object that satisfies
the requirements for appearing in a constant expression and
the lvalue-to-rvalue conversion is immediately applied.

But the definition makes it somewhat clear that a variable is a named
object, and the C standard doesn't use it that way consistently.

(I also ran across a note, N1570 6.7.6.1p3, where the standard conflates
"const" and "constant". At least it's non-normative.)

 

[BartC]

Sad, isn't it?

Ha! I read your post first...

But I guess I will have to find or devise my own alternative to C anyway, as
it doesn't look like I'm going to get much more help here.

The trouble is that pesky language gets everywhere.

 

[Malcolm McLean]

"
But I guess I will have to find or devise my own alternative to C anyway, as
it doesn't look like I'm going to get much more help here.

The trouble is that pesky language gets everywhere.

C is a sort of universal low-level bit bashing language. So most other languages have facilities for
calling C functions.
Whilst C has a few glitches, basically you can have either efficiency, which means raw
address writes, or you can have safety, which means bounds checking. It's very hard to write an
efficient languages that is also safe.
Most good programmers try to program a language at some point. I've done it myself. But it's very
hard to get a language accepted in the marketplace.

 

[BartC]

C is a sort of universal low-level bit bashing language. So most other
languages have facilities for
calling C functions.

It tends to get used to describe interfaces. So the Win32 API for example is
documented using C function prototypes, C structs, and C macros (with an MS
slant on things; and they now call it C++ but it's still C).

To interface to that from your own language you need to know exactly what a
struct means, the exact widths of the numeric types, the exact amount of
padding used, etc etc.

In general, you want to use a library, it's written in C, comes in a binary
LIB form, and might have a header containing the functions, types and data
structures used; however this is not usually designed to be human readable,
you're expected to be using a C compiler (sometimes a particular compiler,
set of options, etc).

I remember trying to read STDAFX.H, and it was totally impossible. Binary
APIs are needed not APIs geared to a specific language. You have to get
involved in C source even if you have no intention of writing any yourself.

Most good programmers try to program a language at some point. I've done
it myself. But it's very
hard to get a language accepted in the marketplace.

I wouldn't even bother trying. These are for my own use. But one or two have
been part of my applications and I've produced user manuals for those.

 

[Martin Shobe]

(snip)




I suppose, but in the algebra statement:

X=2

do you call X a variable? Seems to me that you treat is as a variable
in algebraic operations, but then consider it to have the value 2.

In mathematics, X would technically be a free variable that ranges over
the class of things that makes the statement(s) it appears in true. 2 is
a constant. It refers to a particular thing. In this example, the class
of things X ranges over contains only a single value.

It should also be noted that X does not vary between statements. You
have to use the same value in all the statements even when X ranges over
more than one value.

In mathematics, the primary distinction between a variable and a
constant is one of syntax. A variable may be bound to a quantifier while
a constant may not. For example, "There exists an X such that X=2." is
meaningful while "There exists a 2 such that X=2." is not.

I'll let others decide what sort of impact this should have on naming
the parts of a programming language.

Martin Shobe

 

[Stefan Ram]

In mathematics, X would technically be a free variable that ranges over

Mathematics uses variables, but they are not mathematical
objects (they are not sets). They are objects of what I call
»metamathematics«. I define metamathematics as the field
that has the language of mathematics as its object. There is
no common, well-established, formal definition of »variable«
in mathematics, but this term is defined indeed in some
metamathematical theories.

»Free variable« is a term that is used in metamathematics,
for example, in the lambda-calculus or when talking about
referential transparency. But I believe one can graduate in
mathematics without having ever heard a formal definition of
»variable« or »free variable«. The meaning of »free
variable« depends on the theory chosen. I have an idea of
what a »free variable« is in the lambda calculus, but the
same term might have a different meaning in another
metamathematical theory.

 

[Martin Shobe]

Mathematics uses variables, but they are not mathematical
objects (they are not sets). They are objects of what I call
»metamathematics«. I define metamathematics as the field
that has the language of mathematics as its object. There is
no common, well-established, formal definition of »variable«
in mathematics, but this term is defined indeed in some
metamathematical theories.

Not everything in mathematics is a set. Classes and categories are two
rather well-known exceptions. Furthermore, regardless of how you define
metamathematics, most mathematicians would also consider mathematical
study of the language of mathematics a part of mathematics. (See
mathematical logic.)

»Free variable« is a term that is used in metamathematics,
for example, in the lambda-calculus or when talking about
referential transparency. But I believe one can graduate in
mathematics without having ever heard a formal definition of
»variable« or »free variable«. The meaning of »free
variable« depends on the theory chosen. I have an idea of
what a »free variable« is in the lambda calculus, but the
same term might have a different meaning in another
metamathematical theory.

Mathematics is a vast field. One can graduate in mathematics without
ever having heard a formal definition of topos as well, but it's still a
part of mathematics. Yes, there are details about variables that vary
from language to language: which symbols are variables and which are
not, are the variables typed, sorted, etc. Still, there are other things
which are consistent across all formal languages: variables range over
classes of things, they are symbols, they can be bound to quantifiers
(though the quantifier might also have to be of the right type and/or
sort), etc.

Martin Shobe

 

[BartC]

So you should be able to chew up a language specification and spit it out.

I'm not here to sell anything, and I don't like pushing my own projects.

If the discussion is about how a C-related language feature can or can't be
implemented, then I might use my own work as an example (especially if I've
already implemented it and it works just fine! Or maybe it didn't work so
well, then I can give the benefit of my experience).

There is absolutely no reason to give out, in a C group, complete language
specs for what are private and/or experimental projects. I'm interested in
discussing elements of language design, which often crops up in this group,
and that's it.

And in the case of my current projects, these started off a few months ago
as a common *syntax* to be used as a way of writing mainstream languages (I
experimented with Python, Lisp, and Lua as well as C and C-style languages).
So there was no specification as such, as that depended on the target.

Anyway, that project evolved (because I didn't want to write using other
people's languages, even using my syntax!) into two, more specialised
branches. One was to target my own interpreted bytecode language, which
works extremely well.

The other was to target C, which also worked reasonably well, but with many
problems (such as not being able to trap many classes of errors early
enough). That project then became an independent language, still generating
C, but having its own type system for error checking.

I've put together a very brief spec for this one, detailing only its data
types and saying something about its type system, and that's here:

http://pastebin.com/cnTkv1H0

Comparison with C may or may not be of interest.

(Any discussion about that, best somewhere else such as comp.lang.misc.)