Basic Language Concepts Discussion

Discussions based on BasicLanguageConcepts

"Value" as given is awkward. It implies it's a form of an "expression". And values don't have to "have" types. I will agree they probably need to be "associated with" at least one type, but I don't agree with "has". I'd like cited justification for using "has". -t

Please demonstrate a typeless value. I've changed it to "belongs to", which fits nicely with the definition of 'type'.

But what does "belongs to" mean? How does one measure belongativity, including measuring that belongativity is absent? Otherwise we cannot check to see that something is NOT a "value". If a definition for X is that it has feature Y and feature Z, there should be a clear way to verify that Y and Z are present, otherwise Y and Z are not key features (or the definition is ambiguous).

It's an abstraction, that follows logically from the definition of 'type'. 3 "belongs to" or is an integer; 3.5 "belongs to" or is a float, etc.

Without a set-oriented background laid out, that's not clear.

I'm assuming a ComputerScience background, so it shouldn't be a problem.

If you mix a very basic style with assumptions of prior knowledge, it will be helpful to neither party.

Another suggestion, say "one or more types".

Where do you suggest I say "one or more types"? Whilst the descriptions are concise to the point of being (deliberately) terse, they are not basic in an introductory sense, they are basic in a foundational sense. They wouldn't make much sense to someone without reasonable experience of programming languages.

Re: "The result of evaluating an expression." - Values can be read in from some other source, not just from expressions.

What other sources would those be?

File, database, web service, etc.

Values still result from evaluating expressions. That you can persist and/or exchange them is an implementation detail. Values are not formed by I/O; I/O is merely a (theoretically irrelevant) pipe through which an existing value passes.

No they don't. And even if we did define them that way, that only describes the source of values, not what they are. It's like defining a phone as "that which comes out of a phone factory". While perhaps technically accurate, it's mostly a UselessTruth.

If it is technically accurate -- which it is -- that is sufficient for defining the bases of programming languages.

UselessTruth's often are.

Given that this is a set of definitions rather than a comprehensive survey, embracing the "UselessTruth" seems entirely appropriate.

"Variable" - "Chang-able reference" is awkward. -t

I've changed it.

Still awkward. "Reference" is an arbitrary implementation detail, which the definition should not select.

"Reference" isn't an implementation detail. You appear to be conflating "reference" as in a C#/Java pointer-like language construct with "reference" as in (e.g.) 'A refers to (or makes reference to) B'.

What does it mean here then? If that's not clear, it doesn't help the definition.

What it means is that a variable V can refer to value T now, and can refer to value T' later. It's another way of saying a variable can contain a value, hold a value, etc.

That it change reference to a different version of a "value" is an implementation detail or a selection of an arbitrary model.

It's not a different version of a value, it's a different value. Otherwise, the variable hasn't varied. How would you define "variable" so it isn't dependent on "an implementation detail or a selection of an arbitrary model"?

I can't. I don't know how. Apparently nobody else does either. That's the problem with definitions of "variable", "value", and "types": they are either VagueOrArbitrary.

No, they're not. What they are is abstract. The definitions above are what variables, values and types are -- in abstract terms -- without reference to any particular implementation detail or model. Find an imperative programming language that doesn't fit the definitions above.

To be precise enough relate to in an everybody mechanical/physical sense, one has to pick a somewhat arbitrary model/representation/implementation. Otherwise, it's vague aether-talk or quantum-physics-like. Nobody has found a clean way out of this trap.

There is no trap. You're simply conflating "abstract" with "vague."

I don't like the usage of "associated with". Everything in a program "is associated with" every other thing in it, in at least one way. For example, they all have the common association of "being in the same program".

Of course, but that's not what we're talking about, is it? If we are talking about, say, the association between a value and its type, we're talking about something much more specific than the fact that they're both in the same program. Obviously, we're talking about the fact that if you know one, you know the other.

How does the reader know what you are talking about? They cannot read your mind.

Again, BasicLanguageConcepts assumes ComputerScience knowledge and a familiarity with programming languages. As such, the framing of "associated with" should be clear.

Then the title is misleading.

No, it's "basic" as in "the basis for", not "basic" as in "for beginners". Given that this entire Wiki isn't for beginners, I don't think it's a problem. I'll add some text to BasicLanguageConcepts to make it clear.

Either way, it would be helpful to explicitly define/constrain "associated with" beyond those words alone. "Graduates should JUST KNOW what I mean" is insufficient.

What would you suggest as an alternative?

Explicitness.

I thought it was explicit. What would you suggest as an alternative to make it more explicit?

I could write that a type T is a pair V, O where V is a set of values and O is a set of operators, but that seems unnecessary.

CategoryProgrammingLanguage CategoryLanguageImplementation