Darren New wrote:
Andreas Rossberg wrote:
Yes, technically you are right. But this makes a pretty weak notion of
mutability. All stateful data structures had to stay within their
lexical scope, and could never be passed to a function.
Not really. The way Hermes handles
by far the worst
incarnation of aliasing issues to the table.
- Andreas
--
Andreas Rossberg, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Marshall wrote:
Okay, sure. But for the problem you describe, both imperativeness
and the presence of pointers is each necessary but not sufficient;
it is the two together that causes the problem. So it strikes
me (again, a very minor point) as inaccurate to describe this as
a problem with
an *aspect* of mutability
in lower-level languages.
Again, I disagree: it is posible to have mutability without
pointers/identity/objects.
OK, if you prefer: it is an aspect of first-class mutability - which is
present in almost all imperative languages I know. :-)
- Andreas
--
Andreas Rossberg
David Hopwood wrote:
George Neuner wrote:
All of this presupposes that you have a high level of confidence in
the compiler. I've been in software development for going in 20 years
now and worked 10 years on high performance, high availability
systems. In all that time I have yet to meet a
David Hopwood wrote:
(defun blackhole (argument)
(declare (ignore argument))
#'blackhole)
I believe this example requires recursive types. It can also be expressed
in a gradual typing system, but possibly only using an unknown ('?') type.
ISTR that O'Caml at one point (before version
David Hopwood wrote:
(In the case of eval, OTOH,
the erroneous code may cause visible side effects before any run-time
error occurs.)
Not necessarily. You can replace the primitive eval by compile, which
delivers a function encapsulating the program, so you can check the type
of the
Gabriel Dos Reis wrote:
[EMAIL PROTECTED] writes:
| think that it is too relevant for the discussion at hand. Moreover,
| Harper talks about a relative concept of C-safety.
Then, I believe you missed the entire point.
I think the part of my reply you snipped addressed it well enough.
Marshall wrote:
What we generally (in programming) call variables are locals
and globals. If the languages supports an update operation
on those variables, then calling them variables makes sense.
But variable has become such a catch-all term that we call
public static final int FOO =
David Hopwood wrote:
Values refers to the concrete values existent in the semantics of a
programming language. This set is usually infinite, but basically fixed.
To describe the set of values of an abstract type you would need
fresh values that did not exist before (otherwise the abstract type
Chris Uppal wrote:
Well, it seems to me that you are /assuming/ a notion of what kinds of
logic can be called type (theories), and I don't share your
assumptions. No offence intended.
OK, but can you point me to any literature on type theory that makes a
different assumption?
'Fraid not.
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
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
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
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
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
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
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
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
Marshall wrote:
While we're on the topic of terminology, here's a pet peeve of
mine: immutable variable.
immutable = can't change
vary-able = can change
Clearly a contradiction in terms.
If you have a named value that cannot be updated, it makes
no sense to call it variable since it
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, and
constraints on the
Darren New wrote:
As far as I know, LOTOS is the only
language that *actually* uses abstract data types
Maybe I don't understand what you mean with ADT here, but all languages
with a decent module system support ADTs in the sense it is usually
understood, see ML for a primary example.
Vesa Karvonen wrote:
Indeed, the ability to declare a new type that has the exact same
underlying representation and isomorphically identical operations but
not be the same type is something I find myself often missing in
languages. It's nice to be able to say this integer represents vertical
Darren New wrote:
Maybe I don't understand what you mean with ADT here, but all
languages with a decent module system support ADTs in the sense it is
usually understood, see ML for a primary example.
OK. Maybe some things like ML and Haskell and such that I'm not
intimately familiar
Chris F Clark wrote:
A static
type system eliminates some set of tags on values by syntactic
analysis of annotations (types) written with or as part of the program
and detects some of the disallowed compuatations (staticly) at compile
time.
Explicit annotations are not a necessary
Rob Thorpe wrote:
No, that isn't what I said. What I said was:
A language is latently typed if a value has a property - called it's
type - attached to it, and given it's type it can only represent values
defined by a certain class.
it [= a value] [...] can [...] represent values?
Easy,
Rob Thorpe wrote:
No, that isn't what I said. What I said was:
A language is latently typed if a value has a property - called it's
type - attached to it, and given it's type it can only represent values
defined by a certain class.
it [= a value] [...] can [...] represent values?
???
I just
David Squire wrote:
Andreas Rossberg wrote:
Rob Thorpe wrote:
No, that isn't what I said. What I said was:
A language is latently typed if a value has a property - called it's
type - attached to it, and given it's type it can only represent
values
defined by a certain class
Rob Thorpe wrote:
Andreas Rossberg wrote:
Rob Thorpe wrote:
A language is latently typed if a value has a property - called it's
type - attached to it, and given it's type it can only represent values
defined by a certain class.
it [= a value] [...] can [...] represent values?
???
I just
31 matches
Mail list logo
