|
|
A binding is an association of a name to a value within a module. Both variable and
constant bindings can be defined.
|
|
fun-
principal
|
In a define
|
|
Chris
Page
|
"constant" is probably a bad choice of terms. They're really
just
"read-only variables". A module constant can change between
runs of a
program, since they can be initialized from arbitrary code.
For
example, a constant could contain the IP address of the
computer it's
running on.
|
|
|
|
|
|
|
|
|
|
> But what do you mean above by a binding?
A binding is a name in some namespace, bound to a value. For example,
the name of every generic function, module variable, and local variable
is a "binding".
>>> list is not taken into account for selecting the correct procedure.
>>> Even Langauges like
>>> Ada 95 are able to do this!
>>
>> Again, functions are just bare methods that happen to be named. GFs
>> are a different kind of object, that is callable too, but does
method
>> selection.
>
> This is what i mean by a flaw. I can't understand why this distinction
> is made?!
Note that when you define a method, it doesn't get a binding. Instead,
only the generic function has a name associated with it. The methods
are referred to by the generic function.
In Ada or C++ you can use "overloading" to have multiple functions with
different signatures, and the compiler treats each one as a separate
function. Since they are statically-typed languages, the compiler
always knows the exact types of the arguments at every call site, which
means it can always decide which function to call at compile-time based
upon the argument types.
In addition, each of those functions can only handle arguments of one
exact type. A C++ function that accepts int cannot also accept a float
in the same argument position.
In contrast, Dylan supports dynamic programming, where the exact types
of all the arguments at a given call site may not be known. In fact,
the types don't have to be known at all for the program to compile and
run correctly.
At runtime, argument types are used to select which method of a generic
function to call. This provides a similar behavior to "overloading",
except that the types don't have to be known at compile time. In fact,
the set of methods don't have to be known at compile time, either. The
set of methods in a generic function can be changed at runtime.
Since the compiler may not be able to determine which method to call,
the only information it can always rely upon to compile a function call
is the name of the generic function being called.
In Dylan, the name of a generic function identifies a "family" of
methods, and the generic function must have a unique name. In a way,
it's just a variation of "overloading" in C++, but it's more flexible
and powerful. Every generic function is like a set of overloaded,
non-member functions, and every method is like a virtual member
function in that you can have multiple methods handling different
subclasses of arguments.
By the way, if multiple generic functions had the same name, Dylan
would have to have yet another level of dispatching added to determine
which generic to call, and then determine which method to call. This
may or may not be a good idea, but Dylan doesn't have a way to do that,
currently. Instead, each generic is uniquely identified by its name and
function calls using that name can be successfully compiled.
