Are there some non-OOP programming languages that does not allow you to make a variable private? [closed]

Question

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)?

Answer 1

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

Answer 2

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.

Answer 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.

Answer 4

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.