Darren New [EMAIL PROTECTED] writes:
Marshall wrote:
I can't see how you'd call + on a and b if you think they might
not be numbers.
Now substitute for + and see if you can make the same argument. :-)
Sure. Properly extended to handle strings, abc def might return
true.
--
Duane Rettig
Chris Uppal wrote:
Maybe you are thinking that I mean that /because/ the JVM does verification,
etc, at runtime the system is hybrid ?
Anyway that is /not/ what I mean. I'm (for these purposes) completely
uninterested in the static checking done by the Java to bytecode translator,
javac.
Marshall schreef:
Rob Thorpe:
Can I make a type in C that can only have values between 1 and 10?
How about a variable that can only hold odd numbers, or, to make it
more difficult, say fibonacci numbers?
Well, of course you can't in *C*; you can barely zip you pants with C.
But I believe
Dr.Ruud wrote:
You can write self-modifying code in C,
No, by violating the standards and invoking undefined behavior, you can
write self-modifying code. I wouldn't say you're still in C any more, tho.
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of
Anton van Straaten wrote:
Andreas Rossberg wrote:
Rob Warnock wrote:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
1.1 Semantics
...
Scheme has latent as opposed to manifest types. Types are assoc-
iated with values (also called objects) rather than
Dr.Ruud wrote:
Marshall schreef:
Rob Thorpe:
Can I make a type in C that can only have values between 1 and 10?
How about a variable that can only hold odd numbers, or, to make it
more difficult, say fibonacci numbers?
Well, of course you can't in *C*; you can barely zip you pants
I thought about this in the context of reading Anton's latest post to
me, but I'm just throwing out an idea. It's certainly too fuzzy in my
mind at the moment to consider it in any way developed. I'm sure it's
just as problematic, if not more so, as any existing accounts of dynamic
types.
Marshall [EMAIL PROTECTED] wrote:
I stand corrected: if one is using C and writing self-modifying
code, then one *can* zip one's pants.
I believe you'd need quite the creative USB-based or similar peripheral
device, as well.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ
David Hopwood wrote:
Marshall wrote:
Chris Smith wrote:
Marshall [EMAIL PROTECTED] wrote:
I think what this highlights is the fact that our existing terminology
is not up to the task of representing all the possible design
choices we could make. Some parts of dynamic vs. static
a mutually
A statically type language requires you to think about two models of
your program at the same time: the static type model and the dynamic
behavioral model. A static type system ensures that these two
_different_ (that's important!) perspectives are always in sync.
I have trouble
Marshall wrote:
Andreas Rossberg wrote:
Chris Uppal wrote:
I have never been very happy with relating type to sets of values (objects,
whatever).
Indeed, this view is much too narrow. In particular, it cannot explain
abstract types, which is *the* central aspect of decent type systems.
What
Rob Warnock wrote:
Here's what the Scheme Standard has to say:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
1.1 Semantics
...
Scheme has latent as opposed to manifest types. Types are assoc-
iated with values (also called objects) rather than
[EMAIL PROTECTED] wrote:
A statically type language requires you to think about two models of
your program at the same time: the static type model and the dynamic
behavioral model. A static type system ensures that these two
_different_ (that's important!) perspectives are always in sync.
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt to
add two numbers. In a statically typed language, I additionally need to
know that there must a guarantee that a and b will
Andreas Rossberg wrote:
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt
to add two numbers. In a statically typed language, I additionally
need to know that there must a
Andreas Rossberg [EMAIL PROTECTED] writes:
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will
attempt to add two numbers. In a statically typed language, I
additionally need to know that there
Pascal Costanza [EMAIL PROTECTED] writes:
Andreas Rossberg wrote:
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will
attempt to add two numbers. In a statically typed language, I
Pascal Bourguignon [EMAIL PROTECTED] writes:
Moreover, a good proportion of the program and a good number of
algorithms don't even need to know the type of the objects they
manipulate.
For example, sort doesn't need to know what type the objects it sorts
are. It only needs to be given a
Rob Warnock wrote:
Marshall [EMAIL PROTECTED] wrote:
Can you be more explicit about what latent types means?
I'm sorry to say it's not at all natural or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?
Here's what the Scheme
Pascal Costanza wrote:
A statically type language requires you to think about two models of
your program at the same time: the static type model and the dynamic
behavioral model. A static type system ensures that these two
_different_ (that's important!) perspectives are always in sync. This
Andreas Rossberg wrote:
Marshall wrote:
What prohibits us from describing an abstract type as a set of values?
If you identify an abstract type with the set of underlying values then
it is equivalent to the underlying representation type, i.e. there is no
abstraction.
I don't follow. Are
Andreas Rossberg wrote:
[me:]
It's worth noting, too, that (in some sense) the type of an object can
change over time[*].
No. Since a type expresses invariants, this is precisely what may *not*
happen. If certain properties of an object may change then the type of
the object has to
I wrote:
It would be interesting to see what a language designed specifically to
support user-defined, pluggable, and perhaps composable, type systems
would look like.
Since writing that I've come across some thoughts by Gilad Bracha (a Name known
to Java and Smalltalk enthusiasts alike)
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt to
add two numbers. In a statically typed language, I additionally need to
know that there must a guarantee that a and b will always
Chris Uppal wrote:
It's worth noting, too, that (in some sense) the type of an object can
change over time[*].
No. Since a type expresses invariants, this is precisely what may *not*
happen. If certain properties of an object may change then the type of
the object has to reflect that
Pascal Bourguignon wrote:
For example, sort doesn't need to know what type the objects it sorts
are. It only needs to be given a function that is able to compare the
objects.
Sure. That's why any decent type system supports polymorphism of this
sort. (And some of them can even infer which
Dr.Ruud wrote:
Rob Thorpe schreef:
Dr.Ruud:
Marshall:
dynamic types. I don't have a firm definition for
that term, but my working model is runtime type tags. In which
case, I would say that among statically typed languages,
Java does have dynamic types, but C does not. C++ is
Rob Warnock wrote:
Another language which has *neither* latent (dynamic) nor
manifest (static) types is (was?) BLISS[1], in which, like
assembler, variables are just addresses[2], and values are
just a machine word of bits.
360-family assembler, yes. 8086-family assembler, not so much.
--
Darren New schrieb:
Andreas Rossberg wrote:
AFAICT, ADT describes a type whose values can only be accessed by a
certain fixed set of operations.
No. AFAIU, an ADT defines the type based on the operations. The stack
holding the integers 1 and 2 is the value (push(2, push(1, empty(.
David Hopwood wrote:
Rob Thorpe wrote:
Vesa Karvonen wrote:
In comp.lang.functional Anton van Straaten [EMAIL PROTECTED] wrote:
Let me add another complex subtlety, then: the above description misses
an important point, which is that *automated* type checking is not the
whole story.
Marshall wrote:
What prohibits us from describing an abstract type as a set of values?
If you identify an abstract type with the set of underlying values then
it is equivalent to the underlying representation type, i.e. there is no
abstraction.
I don't follow. Are you saying that a set cannot
[EMAIL PROTECTED] wrote:
Are you sure that you aren't confusing *abstract* with *algebraic* data
types?
I've never heard of algebraic data types. It's always been abstract
data types. Perhaps I stopped studying it, and the terminology changed
when many people started to consider
John W. Kennedy wrote:
360-family assembler, yes. 8086-family assembler, not so much.
And Burroughs B-series, not at all. There was one ADD instruction, and
it looked at the data in the addresses to determine whether to add ints
or floats. :-)
--
Darren New / San Diego, CA, USA (PST)
Rob Thorpe wrote:
Its easy to create a reasonable framework.
Luca Cardelli has given the most convincing one in his seminal tutorial
Type Systems, where he identifies typed and safe as two orthogonal
dimensions and gives the following matrix:
| typed | untyped
George Neuner sez:
On Wed, 21 Jun 2006 16:12:48 + (UTC), Dimitri Maziuk
[EMAIL PROTECTED] wrote:
George Neuner sez:
On Mon, 19 Jun 2006 22:02:55 + (UTC), Dimitri Maziuk
[EMAIL PROTECTED] wrote:
Yet Another Dan sez:
... Requiring an array index to be an integer is considered a typing
Matthias Blume [EMAIL PROTECTED] writes:
Pascal Bourguignon [EMAIL PROTECTED] writes:
Moreover, a good proportion of the program and a good number of
algorithms don't even need to know the type of the objects they
manipulate.
For example, sort doesn't need to know what type the objects it
Pascal Bourguignon [EMAIL PROTECTED] writes:
Matthias Blume [EMAIL PROTECTED] writes:
Pascal Bourguignon [EMAIL PROTECTED] writes:
Moreover, a good proportion of the program and a good number of
algorithms don't even need to know the type of the objects they
manipulate.
For example, sort
Marshall wrote:
In this simple example,
the static case is better, but this is not free, and the cost
of the static case is evident elsewhere, but maybe not
illuminated by this example.
Ugh, please forgive my ham-fisted use of the word better.
Let me try again:
In this simple example, the
Joe Marshall wrote:
What we need is an FAQ entry for how to talk about types with people
who are technically adept, but non-specialists. Or alternatively, an
FAQ of how to explain the term `dynamic typing' to a type theorist.
You could point people at
a regular series on object-oriented
Marshall [EMAIL PROTECTED] writes:
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt to
add two numbers. In a statically typed language, I additionally need to
know that there must a
Matthias Blume [EMAIL PROTECTED] writes:
Pascal Bourguignon [EMAIL PROTECTED] writes:
Matthias Blume [EMAIL PROTECTED] writes:
Pascal Bourguignon [EMAIL PROTECTED] writes:
Moreover, a good proportion of the program and a good number of
algorithms don't even need to know the type of the
Chris Smith wrote:
Joachim Durchholz [EMAIL PROTECTED] wrote:
Assume a language that
a) defines that a program is type-correct iff HM inference establishes
that there are no type errors
b) compiles a type-incorrect program anyway, with an establishes
rigorous semantics for such
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will attempt to
add two numbers. In a statically typed language, I additionally need to
know that there must a guarantee that a and b will always
Marshall schrieb:
immutable = can't change
vary-able = can change
Clearly a contradiction in terms.
Not in mathematics.
The understanding there is that a variable varies - not over time, but
according to the whim of the usage. (E.g. if a function is displayed in
a graph, the parameter
Andreas Rossberg schrieb:
Joachim Durchholz wrote:
It's worth noting, too, that (in some sense) the type of an object
can change over time[*].
No. Since a type expresses invariants, this is precisely what may
*not* happen.
No. A type is a set of allowable values, allowable operations,
Andreas Rossberg schrieb:
(Btw, Pascal did not have it either, AFAIK)
Indeed.
Some Pascal dialects have it.
Regards,
Jo
--
http://mail.python.org/mailman/listinfo/python-list
Joachim Durchholz wrote:
A type is the encoding of these properties. A type
varying over time is an inherent contradiction (or another abuse of the
term type).
No. It's just a matter of definition, essentially.
E.g. in Smalltalk and Lisp, it does make sense to talk of the type of
a
Xah Lee wrote:
in March, i posted a essay “What is Expressiveness in a Computer
Language”, archived at:
http://xahlee.org/perl-python/what_is_expresiveness.html
I was informed then that there is a academic paper written on this
subject.
On the Expressive Power of Programming Languages
Claudio Grondi [EMAIL PROTECTED] wrote:
Looking this thread growing it appears to me, that at least one thing
becomes evident here:
Xah unwillingness to learn from the bad past experience contaminates
others (who are still posting to his trolling threads).
Here another try to rescue
Claudio Grondi schrieb:
Looking this thread growing it appears to me, that at least one thing
becomes evident here:
Xah unwillingness to learn from the bad past experience contaminates
others (who are still posting to his trolling threads).
This is actually one of the most interesting
Rob Thorpe wrote:
David Hopwood wrote:
As far as I can tell, the people who advocate using typed and untyped
in this way are people who just want to be able to discuss all languages in
a unified terminological framework, and many of them are specifically not
advocates of statically typed
Timo Stamm schreef:
This is actually one of the most interesting threads I have read in a
long time. If you ignore the evangelism, there is a lot if
high-quality information and first-hand experience you couldn't find
in a dozen books.
Much of what is talked about, is in these articles (and
George Neuner wrote:
The point is really that the checks that prevent these things
[such as 'array index out of bounds']
must be
performed at runtime and can't be prevented by any practical type
analysis performed at compile time. I'm not a type theorist but my
opinion is that a static
Marshall wrote:
Can you be more explicit about what latent types means?
I'm sorry to say it's not at all natural or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?
Sorry, that was a huge omission. (What I get for posting at 3:30am.)
Pascal Bourguignon wrote:
Pascal Costanza [EMAIL PROTECTED] writes:
Andreas Rossberg wrote:
Pascal Costanza wrote:
Consider a simple expression like 'a + b': In a dynamically typed
language, all I need to have in mind is that the program will
attempt to add two numbers. In a statically typed
Pascal Bourguignon wrote:
But it's always possible at run-time that new functions and new
function calls be generated such as:
(let ((x two))
(eval `(defmethod g ((self ,(type-of x))) t))
(eval `(defmethod h ((x ,(type-of x)) (y string))
(,(intern (format nil
Andreas Rossberg wrote:
Marshall wrote:
What prohibits us from describing an abstract type as a set of values?
If you identify an abstract type with the set of underlying values then
it is equivalent to the underlying representation type, i.e. there is no
abstraction.
I don't follow. Are
Vesa Karvonen wrote:
In comp.lang.functional Anton van Straaten [EMAIL PROTECTED] wrote:
[...]
This static vs dynamic type thing reminds me of one article written by
Bjarne Stroustrup where he notes that Object-Oriented has become a
synonym for good. More precisely, it seems to me that
Rob Thorpe wrote:
So, will y'all just switch from using dynamically typed to latently
typed, and stop talking about any real programs in real programming
languages as being untyped or type-free, unless you really are
talking about situations in which human reasoning doesn't come into
play? I
Andreas Rossberg wrote:
Rob Warnock wrote:
Here's what the Scheme Standard has to say:
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
1.1 Semantics
...
Scheme has latent as opposed to manifest types. Types are assoc-
iated with values (also
Joe Marshall wrote:
That's the important point: I want to run broken code.
I want to make sure I understand. I can think of several things
you might mean by this. It could be:
1) I want to run my program, even though I know parts of it
are broken, because I think there are parts that are not
Joachim Durchholz wrote:
Marshall schrieb:
immutable = can't change
vary-able = can change
Clearly a contradiction in terms.
Not in mathematics.
So stipulated.
However, it *is* a contradiction in English. Now, we often redefine
or narrow terms for technical fields. However, when we
Timo Stamm wrote:
This is actually one of the most interesting threads I have read in a
long time. If you ignore the evangelism, there is a lot if high-quality
information and first-hand experience you couldn't find in a dozen books.
Hear hear! This is an *excellent* thread. The evangelism is
Anton van Straaten wrote:
Vesa Karvonen wrote:
This static vs dynamic type thing reminds me of one article written by
Bjarne Stroustrup where he notes that Object-Oriented has become a
synonym for good. More precisely, it seems to me that both camps
(static dynamic) think that typed
Anton van Straaten wrote:
Marshall wrote:
Can you be more explicit about what latent types means?
I'm sorry to say it's not at all natural or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?
Sorry, that was a huge omission. (What
Chris Smith [EMAIL PROTECTED] wrote:
I see it as quite reasonable when there's an effort by several
participants in this thread to either imply or say outright that static
type systems and dynamic type systems are variations of something
generally called a type system [...]
I didn't say
Marshall wrote:
Joe Marshall wrote:
They *do* have a related meaning. Consider this code fragment:
(car a string)
[...]
Both `static typing' and `dynamic typing' (in the colloquial sense) are
strategies to detect this sort of error.
The thing is though, that putting it that way makes it
David Hopwood wrote:
Pascal Costanza wrote:
Rob Thorpe wrote:
Pascal Costanza wrote:
Matthias Blume wrote:
Pascal Costanza [EMAIL PROTECTED] writes:
(slot-value p 'address) is an attempt to access the field 'address in
the object p. In many languages, the notation for this is p.address.
Rob Thorpe [EMAIL PROTECTED] writes:
Andreas Rossberg wrote:
No, variables are insignificant in this context. You can consider a
language without variables at all (such languages exist, and they can
even be Turing-complete) and still have evaluation, values, and a
non-trivial type
David Hopwood wrote:
Oh, but it *does* make sense to talk about dynamic tagging in a statically
typed language.
It even makes perfect sense to talk about dynamic typing in a statically
typed language - but keeping the terminology straight, this rather
refers to something like described in
Matthias Blume wrote:
Rob Thorpe [EMAIL PROTECTED] writes:
I think we're discussing this at cross-purposes. In a language like C
or another statically typed language there is no information passed
with values indicating their type.
You seem to be confusing does not have a type with no
Rob Thorpe wrote:
I think this should make it clear. If I have a xyz in lisp I know it
is a string.
If I have xyz in an untyped language like assembler it may be
anything, two pointers in binary, an integer, a bitfield. There is no
data at compile time or runtime to tell what it is, the
Andreas Rossberg schrieb:
Rob Thorpe wrote:
Hmm. You're right, ML is no-where in my definition since it has no
variables.
Um, it has. Mind you, it has no /mutable/ variables, but that was not
even what I was talking about.
Indeed. A (possibly nonexhaustive) list of program entities that
Matthias Blume schrieb:
Joachim Durchholz [EMAIL PROTECTED] writes:
Matthias Blume schrieb:
Perhaps better: A language is statically typed if its definition
includes (or ever better: is based on) a static type system, i.e., a
static semantics with typing judgments derivable by typing rules.
Pascal Costanza schrieb:
(It's really important to understand that the idea is to use this for
deployed programs - albeit hopefully in a more structured fashion - and
not only for debugging. The example I have given is an extreme one that
you would probably not use as such in a real-world
Anton van Straaten wrote:
But a program as seen by the programmer has types: the programmer
performs (static) type inference when reasoning about the program, and
debugs those inferences when debugging the program, finally ending up
with a program which has a perfectly good type scheme. It's
Darren New wrote:
[me:]
Personally, I would be quite happy to go there -- I dislike the idea
that a value has a specific inherent type.
Interestingly, Ada defines a type as a collection of values. It works
quite well, when one consistantly applies the definition.
I have never been very
David Hopwood wrote:
When people talk
about types being associated with values in a latently typed or
dynamically typed language, they really mean *tag*, not type.
I don't think that's true. Maybe /some/ people do confuse the two, but I am
certainly a counter-example ;-)
The tag (if any) is
Chris Smith wrote:
It would be interesting to see what a language designed specifically to
support user-defined, pluggable, and perhaps composable, type systems
would look like. [...]
You mean in terms of a practical programming language? If not, then
lambda calculus is used in
So, will y'all just switch from using dynamically typed to latently
typed, and stop talking about any real programs in real programming
languages as being untyped or type-free, unless you really are
talking about situations in which human reasoning doesn't come into
play? I think you'll find
Chris Uppal wrote:
I have never been very happy with relating type to sets of values (objects,
whatever).
Indeed, this view is much too narrow. In particular, it cannot explain
abstract types, which is *the* central aspect of decent type systems.
There were papers observing this as early as
Joachim Durchholz wrote:
Pascal Costanza schrieb:
(It's really important to understand that the idea is to use this for
deployed programs - albeit hopefully in a more structured fashion -
and not only for debugging. The example I have given is an extreme one
that you would probably not use
Rob Thorpe [EMAIL PROTECTED] writes:
Matthias Blume wrote:
Rob Thorpe [EMAIL PROTECTED] writes:
I think we're discussing this at cross-purposes. In a language like C
or another statically typed language there is no information passed
with values indicating their type.
You seem to be
Chris Uppal schrieb:
Chris Smith wrote:
I think Marshall got this one right. The two are accomplishing
different things. In one case (the dynamic case) I am safeguarding
against negative consequences of the program behaving in certain non-
sensical ways. In the other (the static case) I am
Matthias Blume schrieb:
Joachim Durchholz [EMAIL PROTECTED] writes:
Matthias Blume schrieb:
Joachim Durchholz [EMAIL PROTECTED] writes:
Matthias Blume schrieb:
Perhaps better: A language is statically typed if its definition
includes (or ever better: is based on) a static type system,
Matthias Blume wrote:
Rob Thorpe [EMAIL PROTECTED] writes:
Matthias Blume wrote:
Rob Thorpe [EMAIL PROTECTED] writes:
I think we're discussing this at cross-purposes. In a language like C
or another statically typed language there is no information passed
with values indicating
Pascal Costanza schrieb:
Static type systems potentially change the semantics of a
language in ways that cannot be captured by dynamically typed languages
anymore, and vice versa.
Very true.
I also suspect that's also why adding type inference to a
dynamically-typed language doesn't give
Chris Smith wrote:
When I used the word type above, I was adopting the
working definition of a type from the dynamic sense. That is, I'm
considering whether statically typed languages may be considered to also
have dynamic types, and it's pretty clear to me that they do.
I suppose this
Joachim Durchholz wrote:
Hmm... I think this distinction doesn't cover all cases.
Assume a language that
a) defines that a program is type-correct iff HM inference establishes
that there are no type errors
b) compiles a type-incorrect program anyway, with an establishes
rigorous semantics
Rob Thorpe [EMAIL PROTECTED] writes:
No it doesn't. Casting reinterprets a value of one type as a value of
another type.
There is a difference. If I cast an unsigned integer 20 to a
signed integer in C on the machine I'm using then the result I will get
will not make any
Rob Thorpe wrote:
Matthias Blume wrote:
Rob Thorpe [EMAIL PROTECTED] writes:
I think we're discussing this at cross-purposes. In a language like C
or another statically typed language there is no information passed
with values indicating their type.
You seem to be confusing does not have a
Joachim Durchholz wrote:
On a semantic level, the tag is always there - it's the type (and
definitely part of an axiomatic definition of the language).
Tag elimination is just an optimization.
I see what you're saying, but the distinction is a bit fine for me.
If the language has no possible
David Hopwood wrote:
Oh, but it *does* make sense to talk about dynamic tagging in a statically
typed language.
That's part of what makes the term dynamically typed harmful: it implies
a dichotomy between dynamically typed and statically typed languages,
when in fact dynamic tagging and
Chris Uppal wrote:
It's worth noting, too, that (in some sense) the type of an object can change
over time[*]. That can be handled readily (if not perfectly) in the informal
internal type system(s) which programmers run in their heads (pace the very
sensible post by Anton van Straaten today
Marshall schreef:
dynamic types. I don't have a firm definition for
that term, but my working model is runtime type tags. In which
case, I would say that among statically typed languages,
Java does have dynamic types, but C does not. C++ is
somewhere in the middle.
C has union.
--
Affijn,
Nice post! One question:
Anton van Straaten wrote:
3. A really natural term to refer to types which programmers reason
about, even if they are not statically checked, is latent types. It
captures the situation very well intuitively, and it has plenty of
precedent -- e.g. it's mentioned in
Torben Ægidius Mogensen wrote:
That's not true. ML has variables in the mathematical sense of
variables -- symbols that can be associated with different values at
different times. What it doesn't have is mutable variables (though it
can get the effect of those by having variables be
Chris Uppal wrote:
doesn't fit with my intuitions very well -- most noticeably in that the sets
are generally unbounded
Errr, not in Ada. Indeed, not in any machine I know of with a limited
address space.
Andreas Rossberg wrote:
Indeed, this view is much too narrow. In particular, it
Marshall [EMAIL PROTECTED] writes:
Torben Ægidius Mogensen wrote:
That's not true. ML has variables in the mathematical sense of
variables -- symbols that can be associated with different values at
different times. What it doesn't have is mutable variables (though it
can get the effect of
Darren New [EMAIL PROTECTED] writes:
[ ... ] As far as I know, LOTOS is the only
language that *actually* uses abstract data types - you have to use
the equivalent of #include to bring in the integers, for
example. Everything else uses informal rules to say how types work.
There are *tons*
201 - 300 of 466 matches
Mail list logo
