For prototyping convenience I've relied on a number of global variables which are heavily used throughout the code. But now I'd like to make some of them local (but dynamic). Is there any significant downside (eg, efficiency, something else) to declaring them locally special instead of global?
Unpopular features of special variables include:
Lack of referential transparency
This makes it harder to reason functionally about your code. It means that your function produces different results with syntactically equivalent calls.
Introduce bugs
If a lexical variable is defined somewhere in your code (eg. in a system function), you will overwrite it and cause bugs.
Confusing
Special (dynamic) binding is unpopular, and will confuse your readers who are not familiar with it.
Unnecessary
Just use lexical binding, or even anaphoric macros instead.
More information:
Anaphoric macros See Let Over Lambda by Doug Hoyte, or Paul Graham's anaphoric macros.
LiSP (Lisp in Small Pieces) has a section on binding and dynamic binding
Elisp has dynamic binding by default, and enforced dynamic binding for a long time
Many early lisps had dynamic binding, but dropped it.
Related
(define hypot
(lambda (a b)
(sqrt (+ (* a a) (* b b)))))
This is a Scheme programming language.
"define" creates a variable and global binding
lambda creates a procedure
I would like to know if "define" would be considered as an imperative language feature! As long as I know imperative feature is static scoping. I think it is an imperative feature since "define" create a global binding and static scoped looks at global binding for any variable definition where as in dynamic it looks at the current most active binding.
Please help me find the correct answer!! And I would like to know why or why not?
In a Scheme program (define var expr) statement is both a declaration and an initialization. Declarations introduce a new name into the scope. Declarations and initialization are present in both imperative and declarative languages.
However if the same variable is defined twice, then define behave as an assignment - which belongs to the imperative paradigm.
You've put your finger on a subtle and contentious issue. There have long been two informal camps on how define should work, which I would label (very imperfectly, and very controversially!) as the static vs. dynamic camps.
The static camp sees define as a non-side-effecting top-level declaration—it's a syntax that simply defines a name in a top-level scope, just like let is a syntax that defines a name in a local scope. A bit more precisely, this camp tends to see the top-level environment as equivalent to a big letrec with all the defines as the bindings, and all "loose" top-level expressions as the body. This is, incidentally, similar to the way that simple compilers work—read the whole program from one or more files, figure out all of the top-level bindings and generate code with knowledge of the whole program's source text.
The dynamic camp, on the other hand, tends to conceive of the top-level environment as a mutable data structure to which bindings can be added at runtime, and define is then an operation that modifies the top-level environment. This is, incidentally, similar to how simple interactive interpreters work—read definitions interactively from input, one at a time, and incorporate them into the environment as the user provides them.
To give one example, the SLIB library is one that I recall has been criticized for being much too firmly in the "dynamic" camp. If you read Section 1.1 on "features", you see this right from the beginning:
SLIB maintains a list of features supported by a Scheme session. The set of features provided by a session may change during that session.
The documentation for the require form that you use in SLIB to "load" modules continues with this:
Procedure: require feature
If (provided? feature) is true, then require just returns.
Otherwise, if feature is found in the catalog, then the corresponding files will be loaded and (provided? feature) will henceforth return #t. That feature is thereafter provided.
Otherwise (feature not found in the catalog), an error is signaled.
If you read this carefully, you will be struck that it's framing the whole thing as modules being "loaded" at runtime—and not as compile-time linking, which is foreign to the design.
So a "session" is a set of bindings whose keys—not just their values—changes during the runtime of the program. Programs are able to mutate the session with provide and require. They are able to directly observe the mutation with provided?. And it is implied that they can indirectly observe the set of identifiers bound in top-level environment change as a result of require—a call to require causes procedure invocations that would result in a runtime error before its invocation to no longer be so afterwards.
So we can't help but conclude that going by the philosophy of the people who designed this library, define is imperative. But not every Scheme user or implementer shares this philosophy.
First off Scheme is lexically scoped. Define usually is not limited to top level bindings like it is in Racket. It can create bindings within other procedure bodies.
In some implementations define can manipulate state but only for top level definitions. Otherwise it acts like let and binds a variable to the local scope. To actually take advantage of the top-level rebinding programatically is difficult.
So define doesn't introduce an imperative style into scheme code. Compare define to set! and its relatives, which by modify the variable in whatever environment it is bound, thereby allowing imperative style in scheme code.
Every web development framework I've come across, including the best designed ones (Web2Py, Kohana) make use of some form of global variables to represent objects that are global within the application domain- for example, objects representing 'request' and 'response'.
On the other hand, the idea that global variables are bad is one of the fundamental axioms of programming. Indeed the now common disparagements of the singleton pattern usually point to the fact that it's nothing more than globals in disguise, as if that were explanation enough.
I'm trying to understand once and for all how globals can be so condemnable and at the same time be a seemingly indispensable part of all our web frameworks?
What is a global? Taking your text I assume you mean a variable that's declared at global scope. Such variable could be overridden by any assignment and break existing functionality.
However, in OO languages, everything is inside a class and assignment can be wrapped in gettors and settors for properties, or completely hidden behind methods. This gives a safe way of dealing with globals. Note that in proper OO languages (Java, C#, VB.NET etc) it is not possible to have global variables (sometimes a language construct suggests otherwise, but static fields in C# or modules in VB, mixins in Ruby are all wrapped in classes and thus not truly global).
A singleton, you mention it, is a special kind of global. As a designer you can control how many instances run of it. A car only needs one engine, a country only one government (or war breaks loose) and a program needs only one main thread. Globals are a necessity to programming, the real discussion should not be, do we need them, but how to solidly create and use them.
You say that request and response objects are globals in web development. They are not. They are (usually, depending on your toolset) convenience variables set in scope before your code is run. Since a web application can have multiple request objects at any given time, I think these are a poor example of a global variable. They are not (but they are usually local and a singleton to your current thread).
One important feature that you cannot cover in traditional procedural languages (like Basic, Pascal, C) is access control and thus concurrency and thread safety for global variables. In .NET for instance, any static method or property in the BCL (one could say that any static variable is global by definition) is thread-safe by design. Guidelines for user-defined static methods or properties suggest you do the same.
EDIT: the danger is with languages that allow global variables but at the same time propagate themselves as truly OO. While these are wonderful languages, it is indeed dangerous to step out of the protection of OO and create globals in for instance Perl, Python, Ruby, PHP.
I don't know exactly in what context those globals are used in web frameworks, but anything global starts to create problems as soon as you need to have solid access control. If you start to use such a global in concurrently executing program, it's quite hard to say who and when accessed and changed it. It creates so-called shared state. This makes debugging even more difficult.
Anyway, I am not really in favour of such statements. This only leads to oversimplifications. You have to weight you requirements and then decide if this or that pattern brings more positive or negative effects...
In a purely functional language, couldn't one still define an "assignment" operator, say, "<-", such that the command, say, "i <- 3", instead of directly assigning the immutable variable i, would create a copy of the entire current call stack, except replacing i with 3 in the new call stack, and executing the new call stack from that point onward? Given that no data actually changed, wouldn't that still be considered "purely functional" by definition? Of course the compiler would simply make the optimization to simply assign 3 to i, in which case what's the difference between imperative and purely functional?
Purely functional languages, such as Haskell, have ways of modelling imperative languages, and they are not shy about admitting it either. :)
See http://www.haskell.org/tutorial/io.html, in particular 7.5:
So, in the end, has Haskell simply
re-invented the imperative wheel?
In some sense, yes. The I/O monad
constitutes a small imperative
sub-language inside Haskell, and thus
the I/O component of a program may
appear similar to ordinary imperative
code. But there is one important
difference: There is no special
semantics that the user needs to deal
with. In particular, equational
reasoning in Haskell is not
compromised. The imperative feel of
the monadic code in a program does not
detract from the functional aspect of
Haskell. An experienced functional
programmer should be able to minimize
the imperative component of the
program, only using the I/O monad for
a minimal amount of top-level
sequencing. The monad cleanly
separates the functional and
imperative program components. In
contrast, imperative languages with
functional subsets do not generally
have any well-defined barrier between
the purely functional and imperative
worlds.
So the value of functional languages is not that they make state mutation impossible, but that they provide a way to allow you to keep the purely functional parts of your program separate from the state-mutating parts.
Of course, you can ignore this and write your entire program in the imperative style, but then you won't be taking advantage of the facilities of the language, so why use it?
Update
Your idea is not as flawed as you assume. Firstly, if someone familiar only with imperative languages wanted to loop through a range of integers, they might wonder how this could be achieved without a way to increment a counter.
But of course instead you just write a function that acts as the body of the loop, and then make it call itself. Each invocation of the function corresponds to an "iteration step". And in the scope of each invocation the parameter has a different value, acting like an incrementing variable. Finally, the runtime can note that the recursive call appears at the end of the invocation, and so it can reuse the top of the function-call stack instead of growing it (tail call). Even this simple pattern has almost all of the flavour of your idea - including the compiler/runtime quietly stepping in and actually making mutation occur (overwriting the top of the stack). Not only is it logically equivalent to a loop with a mutating counter, but in fact it makes the CPU and memory do the same thing physically.
You mention a GetStack that would return the current stack as a data structure. That would indeed be a violation of functional purity, given that it would necessarily return something different each time it was called (with no arguments). But how about a function CallWithStack, to which you pass a function of your own, and it calls back to your function and passes it the current stack as a parameter? That would be perfectly okay. CallCC works a bit like that.
Haskell doesn't readily give you ways to introspect or "execute" call stacks, so I wouldn't worry too much about that particular bizarre scheme. However in general it is true that one can subvert the type system using unsafe "functions" such as unsafePerformIO :: IO a -> a. The idea is to make it difficult, not impossible, to violate purity.
Indeed, in many situations, such as when making Haskell bindings for a C library, these mechanisms are quite necessary... by using them you are removing the burden of proof of purity from the compiler and taking it upon yourself.
There is a proposal to actually guarantee safety by outlawing such subversions of the type system; I'm not too familiar with it, but you can read about it here.
Immutability is a property of the language, not of the implementation.
An operation a <- expr that copies data is still an imperative operation, if values that refer to the location a appear to have changed from the programmers point of view.
Likewise, a purely functional language implementation may overwrite and reuse variables to its heart's content, as long as each modification is invisible to the programmer. For example, the map function can in principle overwrite a list instead of creating a new, whenever the language implementation can deduce that the old list won't be needed anywhere.
What are some of the optimization steps that this command does
`(optimize speed (safety 0))`
Can I handcode some of these techniques in my Lisp/Scheme program?
What these things do in CL depends on the implementation. What usually happens is: there's a bunch of optimizations and other code transformations that can be applied on your code with various tradeoffs, and these declarations are used as a higher level specification that is translated to these individual transformations. Most implementations will also let you control the individual settings, but that won't be portable.
In Scheme there is no such standard facility, even though some Schemes use a similar approach. The thing is that Scheme in general (ie, in the standard) avoids such "real world" issues. It is possible to use some optimization techniques here and there, but that depends on the implementation. For example, in PLT the first thing you should do is make sure your code is defined in a module -- this ensures that the compiler gets to do a bunch of optimizations like inlining and unfolding loops.
I don't know, but I think the SBCL internals wiki might have some starting points if you want to explore.
Higher speed settings will cause the compiler to work harder on constant folding, compile-time type-inference (hence eliminating runtime dynamic dispatches for generic operations) and other code analyses/transformations; lower safety will skip runtime type checks, array bound checks, etc. For more details, see
Advanced Compiler Use and Efficiency Hints chapter of the CMUCL User's Manual, which applies to both CMUCL and SBCL(more or less).
I often find developers use the terms functional language and dynamic language together, and wonder why are they always being put together.
What are the differences between them? Can a language be both dynamic and functional? Do they complement each other? Why do we need them anyway?
I'm a C# programmer and don't yet understand this whole dynamic/functional thing (C# is going to have some dynamic features in ver 4. Will it also be functional? what's going on here?).
Thanks,
Abraham
To put it in a simple (but not accurate) answer
Dynamic languages are ones in which the Type (Name of the Class) is not as important as compared to its nemesis statically typed languages. A variable may have objects of different types assigned to it at any given point of time. Method invocations are resolved at run-time. This means you lose the benefits of static typing (compiler warnings) but simple methods turn generic - sort(list) works for a list of strings as well as list of ints. e.g. Ruby et. all
Functional languages value immutability. The programs are written in terms of bigger and bigger functions (usually bottom up). The concept of object state and mutability is frowned upon. A function in this context is self-sufficient (The term is Pure as per Wikipedia): everything it needs to produce output, lies in the input that it receives. It also produces no side-effects (unless it explicitly mentions it) and returns consistent output for a given input. This can lead to elegant code (see: fluent interfaces), where input data is pipelined through diff functions to produce the eventual output e.g. LISP et.all
However the boundaries are being muddied with languages picking up the best of all worlds... You could have a language which is both, one or neither.
e.g. predominantly static C# picking up lambda expressions in 3.0 and bringing in dynamic capabilities with 4.0
Dynamic typing, a type system, is orthogonal to 'functional', a programming paradigm.
Dynamic 'languages' are actually dynamically typed. This means that you don't have compile-time checking of your variable types.
Functional languages offer loads of support for e.g. lambda calculus - anonymous functions.
An example of a language that does dynamic typing, and supports anonymous functions: javascript. Ruby has some functional style support, too. And there are others.
Dynamic typing and functional programming are independent concepts. You can have either, neither or both in a language.
Static typing means that types of objects are known at compilation time. In dynamic typing they are known at runtime.
Functional programming means programming style where computation is done by evaluating functions while avoiding state changes. (example: you use recursion instead of for-loops, because a loop would need changing of a counter variable, etc.) This helps to avoid bugs and makes concurrent programming easier. Pure languages require you to program in functional style, others just enable it.
Example languages:
|----------------+---------+---------|
| | Dynamic | Static |
|----------------+---------+---------|
| Functional | LISP | Haskell |
| Not functional | PHP | Java |
|----------------+---------+---------|
Dynamic languages on the other hand are a broader concept. There is no exact definition, but usually the more features of the compiler are moved to the runtime, more dynamic the language is. This means that in dynamic languages you can usually evaluate expressions, change object structure etc. at runtime.
If you're interested in paradigms, the paper Programming Paradigms for Dummies: What Every Programmer Should Know covers them.
In functional programming, state is implicit - the program executes by calling functions which call other functions. In imperative programming and object oriented programming, state is explicit - you change the value of a variable or object's field.
In a way, functional and imperative systems can be seen as duals - what's fixed in one is a dynamic value in the other.
Closures - which trap some explicit, mutable state in an object which can be called as a function - sit somewhere between, being neither pure functional programming but not quite fully fledged objects; they are more like anonymous objects than functions.
'Dynamic languages' is vague term, usually meaning one of the following:
Dynamically Typed Languages - languages which delay determination of type to runtime, but the set of types is fixed. Examples are Smalltalk, Lisps, current Fortress implementations. Some otherwise statically typed languages also allow some dynamic type checks - Java, C#, C++ and Ada. ( it was a failed dynamic type cast from float to int in Ada that crashed Ariane 5 )
Languages with dynamic types - languages where new types can be created at runtime. The most popular is JavaScript. Because you have to run the program to determine the types, it's harder to make IDEs for these with type aware autocompletion.
Languages which are dynamically compiled - languages where new scripts can be compiled at runtime. This is true of bash, JSP, PHP and ASP at the page scale, and true for at a finer scale for lisps and JavaScript which support an 'eval' function which compiles and runs an expression.
Functional languages which are strongly typed often perform a large amount of type inference, so it's common for their programs to have less explicit typing than poorly implemented static typed languages. This can confuse people who have only seen the lack of explicit typing in dynamic typed languages into believing that type inference is the same as dynamic typing.
xtofl has already offered a good overall picture. I can speak to the C# point.
C# has been becoming easier to work with in a functional way for a while now:
C# 2 introduced anonymous methods, which made it easier to create delegates which used state which was otherwise local to a method
C# 3 introduced lambda expressions which are mostly like anonymous methods but even more compact
LINQ support in both C# 3 and .NET 3.5 made it easier to query data in a functional way, chaining together predicates, projections etc
None of the C# 4 features directly contributes to functional programming IMO, although named arguments and optional parameters may make it easier to create/use immutable types, which is one of the biggest features missing from the functional picture IMO.
(There are other things functional languages often have, such as pattern matching and more impressive type inference, but you can write a lot of functional-style code reasonably easily in C#.)
C# 4 will gain some dynamic abilities through the dynamic type (which itself is effectively a static type you can do anything with). This will be somewhat "opt in" - if you never use the dynamic type, C# will still be fully static language. There's no language support for responding dynamically, but the DLR has support for this - if you implement IDynamicMetaObjectProvider or derive from DynamicObject, for example, you can add dynamic behaviour.
I would say that C# isn't becoming a functional language or a dynamic language, but one in which you can code in a functional style and interoperate with dynamic platforms.