I'm wondering if anyone if aware of a language that has support for variables (that could be considered 'global'), and subroutines (functions), but without a concept of parameter passing, local scope, etc. Something where every subroutine has access to every global variable, and only global variables.
BASIC and assembly come immediately to mind.
Of course, this is not construed as a feature. That's why we invent conventions for which global variables should be used for parameter passing.
Related
I've read the spec but I'm still confused how my class differs from [our] class. What are differences and when to use which?
The my scope declarator implies lexical scoping: following its declaration, the symbol is visible to the code within the current set of curly braces. We thus tend to call the region within a pair of curly braces a "lexical scope". For example:
sub foo($p) {
# say $var; # Would be a compile time error, it's not declared yet
my $var = 1;
if $p {
$var += 41; # Inner scope, $var is visible
}
return $var; # Same scope that it was declared in, $var is visible
}
# say $var; # $var is no longer available, the scope ended
Since the variable's visibility is directly associated with its location in the code, lexical scope is really helpful in being able to reason about programs. This is true for:
The programmer (both for their own reasoning about the program, but also because more errors can be detected and reported when things have lexical scope)
The compiler (lexical scoping permits easier and better optimization)
Tools such as IDEs (analyzing and reasoning about things with lexical scope is vastly more tractable)
Early on in the design process of the language that would become Raku, subroutines did not default to having lexical scope (and had our scope like in Perl), however it was realized that lexical scope is a better default. Making subroutine calls always try to resolve a symbol with lexical scope meant it was possible to report undeclared subroutines at compile time. Furthermore, the set of symbols in lexical scope is fixed at compile time, and in the case of declarative constructs like subroutines, the routine is bound to that symbol in a readonly manner. This also allows things like compile-time resolution of multiple dispatch, compile-time argument checking, and so forth. It is likely that future versions of the Raku language will specify an increasing number of compile-time checks on lexically scoped program elements.
So if lexical scoping is so good, why does our (also known as package) scope exist? In short, because:
Sometimes we want to share things more widely than within a given lexical scope. We could just declare everything lexical and then mark things we want to share with is export, but..
Once we get to the point of using a lot of different libraries, having everything try to export things into the single lexical scope of the consumer would likely lead to a lot of conflicts
Packages allow namespacing of symbols. For example, if I want to use the Cro clients for both HTTP and WebSockets in the same code, I can happily use both, and refer to them as Cro::HTTP::Client and Cro::WebSocket::Client respectively.
Packages are introduced by package declarators, such as class, module, grammar, and (with caveats) role. An our declaration will make an installation in the enclosing package construct.
These packages ultimately exist within a top-level package named GLOBAL - which is fitting, since they are effectively globally visible. If we declare an our-scoped variable, it is thus a global variable (albeit hopefully a namespaced one), about which enough has been written that we know we should pause for thought and wonder if a global variable is the best API decision (because, ultimately, everything that ends up visible via GLOBAL is an API decision).
Where things do get a bit blurry, however, is that we can have lexical packages. These are packages that do not get installed in GLOBAL. I find these extremely useful when doing OO programming. For example, I might have:
# This class that ends up in GLOBAL...
class Cro::HTTP::Client {
# Lexically scoped classes, which are marked `my` and thus hidden
# implementation details. This means I can refactor them however I
# want, and never have to worry about downstream fallout!
my class HTTP1Pipeline {
# Implementation...
}
my class HTTP2Pipeline {
# Implementation...
}
# Implementation...
}
Lexical packages can also be nested and contain our-scoped variables, however don't end up being globally visible (unless we somehow choose to leak them out).
Different Raku program elements have been ascribed a default scope:
Subroutines default to lexical (my) scope
Methods default to has scope (only visible through a method dispatch)
Type (class, role, grammar, subset) and module declarations default to package (our) scope
Constants and enumerations default to package (our) scope
Effectively, things that are most often there to be shared default to package scope, and the rest do not. (Variables do force us to pick a scope explicitly, however the most common choice is also the shortest one to type.)
Personally, I'm hesitant to make a thing more visible than the language defaults, however I'll often make them less visible (for example, my on constants that are for internal use, and on classes that I'm using to structure implementation details). When I could do something by exposing an our-scoped variable in a globally visible package, I'll still often prefer to make it my-scoped and provide a sub (exported) or method (visible by virtue of being on a package-scoped class) to control access to it, to buy myself some flexibility in the future. I figure it's OK to make wrong choices now if I've given myself space to make them righter in the future without inconveniencing anyone. :-)
In summary:
Use my scope for everything that's an implementation detail
Also use my scope for things that you plan to export, but remember exporting puts symbols into the single lexical scope of the consumer and risks name clashes, so be thoughtful about exporting particularly generic names
Use our for things that are there to be shared, and when its desired to use namespacing to avoid clashes
The elements we'd most want to share default to our scope anyway, so explicitly writing our should give pause for thought
As with variables, my binds a name lexically, whereas our additionally creates an entry in the surrounding package.
module M {
our class Foo {}
class Bar {} # same as above, really
my class Baz {}
}
say M::Foo; # ok
say M::Bar; # still ok
say M::Baz; # BOOM!
Use my for classes internal to your module. You can of course still make such local symbols available to importing code by marking them is export.
The my vs our distinction is mainly relevant when generating the symbol table. For example:
my $a; # Create symbol <$a> at top level
package Foo { # Create symbol <Foo> at top level
my $b; # Create symbol <$b> in Foo scope
our $c; # Create symbol <$c> in Foo scope
} # and <Foo::<$c>> at top level
In practice this means that anything that is our scoped is readily shared to the outside world by prefixing the package identifier ($Foo::c or Foo::<$c> are synonymous), and anything that is my scoped is not readily available — although you can certainly provide access to it via, e.g., getter subs.
Most of the time you'll want to use my. Most variables just belong to their current scope, and no one has any business peaking in. But our can be useful in some cases:
constants that don't poison the symbol table (this is why, actually, using constant implies an our scope). So you can make a more C-style enum/constants by using package Colors { constant red = 1; constant blue = 2; } and then referencing them as Colors::red
classes or subs that should be accessible but needn't be exported (or shouldn't be because overlapping symbols with builtins or other modules). Exporting symbols can be great, but sometimes it's also nice to have the package/module namespace to remind you what stuff goes with. As such, it's also a nice way to manage options at runtime via subs: CoolModule::set-preferences( ... ). (although dynamic variables can be used to nice effect here as well).
I'm sure others will comment with other times the our scope is useful, but these are the ones from my own experience.
Out of all the features Pharo has, the |a b c| style of declaring temporary variables definitely feels like something that should have stayed in the 80s. Is there any benefit from declaring uninitialized variables and then doing assignment on them rather than having let bindings?
It is true that the IDE will be helpful in making such declarations, but I found it to be annoying when removing assignments as the empty declarations would still remain in.
I don't know the original reason but using Smalltalk every week, I see multiple advantages.
It makes the code more readable. When we see a variable we can know if it's a temporary variable or an instance variable by looking at the declared temporary variables.
It defines the scope of the variable (Since it can be only in the scope of a block for example)
It allows better code completion
I guess it also simplifies the implementation of the Compiler.
Is there a list of items on the web that you should not use when creating a model or variable?
For example, if I wanted to create apartment listings, naming a model something like Property would be problematic in the future and also confusing since property is a built-in Python function.
I did try Googling this, but couldn't come up with anything.
Thanks!
Rules and constraints about naming depend on the programming language. How an identifier/name is bound depends on the language semantics and its scoping rules: an identifer/name will be bound to different element depending on the scope. Scoping is usally lexical (i.e. static) but some language have dynamic scoping (some variant of lisp).
If names are different, there is no confusion in scoping. If identifiers/names are reused accrossed scopes, an identifier/name might mask another one. This is referred as Shadowing. This is a source of confusion.
Certain reserved names (i.e. keywords) have special meaning. Such keyword can simply be forbidden as names of other elements, or not.
For instance, in Smallatalk self is a keyword. It is still possible to declare a temporary variable self, though. In the scope where the temporary variable is visible, self resolves to the temporary variable, not the usual self that is receiver of the message.
Of course, shadowing can happen between regular names.
Scoping rules take types into consideration as well, and inheritance might introduce shadows.
Another source of confusion related to binding is Method Overloading. In statically typed languages, which method is executed depends on the static types at the call site. In certain cases, overloading makes it confusing to know which method is selected. Both Shadowing and Overloading should avoided to avoid confusions.
If your goal is to translate Python to Javascript, and vice versa, I guess you need to check the scoping rules and keywords of both languages to make sure your translation is not only syntactically correct, but also semantically correct.
Generally, programming languages have 'reserved words' or 'keywords' that you're either not able to use or in some cases are but should stay away from. For Python, you can find that list here.
Most words in most natural languages can have different meanings, according to the context. That's why we use specifiers to make the meaning of a word clear. If in any case you think that some particular identifier may be confusing, you can just add a specifier to make it clear. For example ObjectProperty has probably nothing to do with real estate, even in an application that deals with real estate.
The case you present is no different than using generic identifiers with no attached context. For example a variable named limit or length may have completely different meanings in different programs. Just use identifiers that make sense and document their meaning extensively. Being consistent within your own code base would also be preferable. Do not complicate your life with banned term lists that will never be complete and will only make programming more difficult.
The obvious exceptions are words reserved by your programming language of choice - but then again no decent compiler would allow you to use them anyway...
How is COBOL's scope defined? Is it statically scoped?
Cobol has compile time binding for variables, sometimes called static scope.
Within that, Cobol supports several layers of scope within programs:
"External" variables are the equivilent of a Fortran or assembler common section, they are truly global.
"Global Program Scope" variables declared in working storage as global are visible to the entire program in which they are declared AND in all nested subprograms contained in that program.
"Program Scope" variables declared in working storage are visible to the entire program in which they are declared.
"Program Scope" variables declared in local storage are visible to the entire program in which they are declared, but are deleted and reinitialized on every invocation. Think thread scoped, sorta.
"Nested Program Scope" Cobol does not distinguish between programs and functions/procedures, its equvilent of a procedure or function is called a program. An infinite number of programs can be contained within a program, and the variables of each are visible only within the scope of that individual program. You could think of this as function/procedure scope.
The OO extensions that many vendors have, and the 2002 standard, defines the traditional public/protected/private object scope and method scope.
"Cobol" is as old as Radar, Laser, and Scuba, can we please stop acronymizing it?
All variables in a COBOL program are globally scoped. In fact, there are no "scopes" (in traditional COBOL, I'm not messing with OO extensions), but just "modules" or "programs".
Intermodule communication is done via the Linkage Section (usually passed by ref), and also all variables there are visible from the called module.
COBOL uses static (lexical) scope (as do C, C++, Java and Pascal). Dynamic scope is not all that common in the programming world. I think some versions of Lisp and SNOBOL used dynamic scope.
If you are interested in understanding scope with respect to programming languages you should review this document
Due to a wave of criticism to use Global Vars in my Java post, I want to use a language without global vars. One suggestion per answer, thank you.
If you want to avoid side-effects you can use one of the pure functional programming languages like haskell (or erlang or ...), which have only constants. But be prepared for a completely different kind of programming compared to the imperative programming style.
I'm not sure if you literally mean no global variables (values that change), or if you also want to rule out global constants (values that don't change). Haskell is one such language that doesn't have global variables, although it does have global constants (in the form of parameterless functions, essentially). In Haskell, if you want to emulate global state, you have to pass your "global" variables into each function you call. A better description is available from the HaskellWiki.
If you don't want global variables then don't use them. I'm don't see why finding a language that doesn't support them would offer any value. You're dealing with a question of scope. Make your variables exist in the lowest scope possible and you'll be fine. There is no language that doesn't have a global scope.
Java (and similar OOP-languages) doesn't have really global variables, all variables are tied to an instance or a class. But I think you want also outrule the 'simulated' global variables (public fields with the only reason to be accessed from the outside). I don't think any of the popular languages don't allow this, but more uncommon language-concepts may have ways to avoid such things.
Well, I read that Graal is a functional programming language without variables, so I guess that might qualify.
I believe Eiffel doesn't use global variables but that isn't a serious criterion
of whether to use a language or not.
Newspeak has no global namespace and so no global variables, everything is late bound, I think other langages in the BETA family have the same property.
https://en.wikipedia.org/wiki/Newspeak_(programming_language)
The latest one entering this club would be V.