mming, usually based on deep unification, brings by far the worst
incarnation of aliasing issues to the table.
- Andreas
--
Andreas Rossberg, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
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 reall
ll imperative languages I know. :-)
- 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
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 m
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 fun
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 (befor
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 enoug
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?
>
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 a
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
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
---+
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 tha
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 whi
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 t
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
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) rath
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
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 f
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 repres
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. Cl
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
> const
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 "vari
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
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
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:
>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
>>
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
>>&
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 va
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"?
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 ing
31 matches
Mail list logo
