2

In the non-OOP programming languages that I know of, you can't make a variable private (i.e. there is no private keyword), but there are some tricks that you can use to effectively make a variable private (i.e. to only allow certain functions to be able to access the variable), for example the programming language C allows you to use such tricks.

But are there some non-OOP programming languages that does not allow you to use such tricks to make a variable private (i.e. where all variables are accessible by all functions)?

10
  • 1
    Why are there three close votes for this question, but none for retrocomputing.stackexchange.com/questions/17686? – user3840170 Jan 21 at 7:18
  • 4
    Assembly language usually does not have a way to make a variable private. – ecm Jan 21 at 8:15
  • 1
    This appears to be a question without historical scope. If you specify the timeline you are interested in, it would help, even though many answers may focus on historical languages. – Mark Williams Jan 21 at 12:12
  • 2
    @user3840170 The question you referenced is trying to locate the language referred to in this comment " I know I once used a language where the return value of a function needed to be assigned to the name of the function. It's so ancient and obsolete I can't even remember which language it was." This question appears to be asking about languages currently in use. – Mark Williams Jan 21 at 12:17
  • 1
    "Private" is why we have more than one source file, A file isn't just a bag with random content, it represents an access boundary. – another-dave Jan 21 at 13:30
7

The BASIC language did not have the notion of variable scopes. All variables were statically allocated and globally accessible.

2
  • with the exception of DEF FN, kind of.... – Radovan Garabík Jan 21 at 6:56
  • @RadovanGarabík The formal parameters of DEF FN do not keep state across calls, so they are not "variables" per se. – Leo B. Jan 21 at 7:12
5

In C, if a variable has "static" in front of it, it is private to the code module. If someone decides to stick it in a header file, then every source file that #includes that header file will have their own private copy.

1
  • 1
    How does this answer the question? – Vladimir F Jan 21 at 14:34
3

(I guess this isn't really retrocomputing, and more general programming languages theory ...)

"Private" in OOP is tied to a particular object, and non-OOP languages usually don't have objects.

If you allow other constructs:

Module systems in nearly all languages have a concept of "exported" vs. "non-exported" ("private") items.

Scope in procedural languages makes variables accessible only on the static scope where they are defined. If you combine that with constructs that extend the lifetime of the variable (e.g. static in C), you get something like a global private variable.

Rank-2 types in typed functional languages can tie a particular expression to a quantified type variable, and prevents the "escape" from that expression into surrounding code. This is for example used in the ST monad in Haskell.

0

The question is, I think, wrong in its assumptions. Non-object-oriented languages frequently permit private access to symbols (variables, functions, …) without the need to resort to "tricks".

The essential feature, supported by many languages, including every assembler I've used and pretty much every higher-level language that supports separate compilation, is the "source file".

In a given source file, symbols can typically be declared as "internal to this file" or "visible outside this file" (as well as "defined in some other file but used here"). In a decent system, IMO, the default is "internal", since then you have to consciously think about what is not private.

So, yes, we have "private". It's either implicit, or else it's spelled something like "internal" (or .INTRN, etc.)

There were also programming systems that did not support programs split into multiple files; typically early systems. Algol 60 was an example, though implementation-specific extensions sometimes existed. These controlled symbol visibility through lexical scope: the nested block structure helped. Sometimes it was technically necessary to give symbols wider visibility than you'd like, but then, in a one-file program, the author is not trying to access things that he intends that he does not access.

This doesn't answer the question, which I interpret as "is there at least one system that does not allow control of symbol visibility?".

So, yes, there is. It cannot really be otherwise. There must be at least one language that does not have this feature that is really essential to large programming.

One obvious candidate presents itself: BASIC.

The original Dartmouth BASIC had an undifferentiated symbol space. Every symbol (which were all one or two characters) was available throughout the program. There was not even any lexical division into "routines" -- a subroutine call was just a GOSUB to any line number you wanted; like a GOTO but with an address "saved" in case you ever executed a RETURN.

(No slight on BASIC's inventors - it was designed as a Beginner's language)

So that's my answer: BASIC.

3
  • What's the point belaboring an existing answer? – Leo B. Jan 21 at 20:16
  • By the way, Algol 60 had "own" variables in procedures, with the same semantics as "static" locals in C. – Leo B. Jan 21 at 20:17
  • Sure, though that doesn't change the scope of the identifier. (Unlike C, there was no defined way to initialize own, though some implementations guaranteed all-bits-zero, which made the concept more useful) – another-dave Jan 22 at 1:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.