[27981] in Perl-Users-Digest
Perl-Users Digest, Issue: 9345 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 22 14:10:17 2006
Date: Thu, 22 Jun 2006 11:10:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 22 Jun 2006 Volume: 10 Number: 9345
Today's topics:
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <jwkenne@attglobal.net>
Re: What is Expressiveness in a Computer Language rossberg@ps.uni-sb.de
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <dima@127.0.0.1>
Re: What is Expressiveness in a Computer Language <pjb@informatimago.com>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <pjb@informatimago.com>
Re: What is Expressiveness in a Computer Language <pjb@informatimago.com>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: working with perfmon <jgibson@mail.arc.nasa.gov>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Jun 2006 17:21:31 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7echr$8r8i0$3@hades.rz.uni-saarland.de>
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 comparison function to pass
for individual calls, so that the programmer does not have to bother.)
- Andreas
------------------------------
Date: Thu, 22 Jun 2006 17:30:04 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7ed1s$8r8i0$4@hades.rz.uni-saarland.de>
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 possibility. Otherwise you cannot
>>legitimately call it a type.
>
> 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?
> I see no reason,
> even in practise, why a static analysis should not be able to see that the set
> of acceptable operations (for some definition of acceptable) for some
> object/value/variable can be different at different times in the execution.
Neither do I. But what is wrong with a mutable reference-to-union type,
as I suggested? It expresses this perfectly well.
- Andreas
------------------------------
Date: 22 Jun 2006 08:35:55 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150990555.368011.48350@b68g2000cwa.googlegroups.com>
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
> >>> somewhere in the middle.
> >>
> >> C has union.
> >
> > That's not the same thing.
>
> That is your opinion. In the context of this discussion I don't see any
> problem to put C's union under "dynamic types".
Lets put it like this:-
1. In C++ and Java it is possible to make a variable that can A)Take on
many different types and B)Where the programmer can test what the type
is.
2. In C it is possible to make a variable that can do 1A but not 1B.
This is a statement of fact, not opinion.
I call languages that do #1 dynamically typed, in line with common
usage.
> > The value of a union in C can be any of a
> > set of specified types. But the program cannot find out which, and
> > the language doesn't know either.
> >
> > With C++ and Java dynamic types the program can test to find the type.
>
> When such a test is needed for the program with the union, it has it.
What do you mean?
There is no way to test the type of the value inside a union in C.
------------------------------
Date: Thu, 22 Jun 2006 11:37:09 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <GOymg.60$6O1.44@fe11.lga>
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.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
------------------------------
Date: 22 Jun 2006 08:42:09 -0700
From: rossberg@ps.uni-sb.de
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150990929.210041.198580@m73g2000cwd.googlegroups.com>
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()))).
> There's no "internal" representation. The values and operations are
> defined by preconditions and postconditions.
Are you sure that you aren't confusing *abstract* with *algebraic* data
types? In my book, abstract types usually have an internal
representation, and that can even be stateful. I don't remember having
encountered definitions of ADT as restrictive as you describe it.
> Both a stack and a queue could be written in most languages as "values
> that can only be accessed by a fixed set of operations" having the same
> possible internal representations and the same function signatures.
> They're far from the same type, because they're not abstract.
Different abstract types can have the same signature. That does not
make them the same type. The types are distinguished by their identity.
Likewise, two classes can have the same set of methods, without being
the same class (at least in languages that have nominal typing, which
includes almost all typed OOPLs).
> I'm pretty sure in Pascal you could say
>
> Type Apple = Integer; Orange = Integer;
> and then vars of type apple and orange were not interchangable.
No, the following compiles perfectly fine (using GNU Pascal):
program bla;
type
apple = integer;
orange = integer;
var
a : apple;
o : orange;
begin
a := o
end.
- Andreas
------------------------------
Date: 22 Jun 2006 08:44:42 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150991074.705803.211570@m73g2000cwd.googlegroups.com>
David Hopwood wrote:
> Rob Thorpe wrote:
> > Vesa Karvonen wrote:
> >
> >>In comp.lang.functional Anton van Straaten <anton@appsolutions.com> 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. I.e. that compile time/runtime distinction is a kind of
> >>>red herring.
> >>
> >>I agree. I think that instead of "statically typed" we should say
> >>"typed" and instead of "(dynamically|latently) typed" we should say
> >>"untyped".
> [...]
> >>>It's certainly close enough to say that the *language* is untyped.
> >>
> >>Indeed. Either a language has a type system and is typed or has no
> >>type system and is untyped. I see very little room for confusion
> >>here. In my experience, the people who confuse these things are
> >>people from the dynamic/latent camp who wish to see types everywhere
> >>because they confuse typing with safety or having well-defined
> >>semantics.
> >
> > No. It's because the things that we call latent types we use for the
> > same purpose that programmers of static typed languages use static
> > types for.
> >
> > Statically typed programmers ensure that the value of some expression
> > is of some type by having the compiler check it. Programmers of
> > latently typed languages check, if they think it's important, by asking
> > what the type of the result is.
> >
> > The objection here is that advocates of statically typed language seem
> > to be claiming the "type" as their own word, and asking that others use
> > their definitions of typing, which are really specific to their
> > subjects of interest.
>
> 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 languages.
Its easy to create a reasonable framework. My earlier posts show simple
ways of looking at it that could be further refined, I'm sure there are
others who have already done this.
The real objection to this was that latently/dynamically typed
languages have a place in it. But some of the advocates of statically
typed languages wish to lump these languages together with assembly
language a "untyped" in an attempt to label them as unsafe.
------------------------------
Date: Thu, 22 Jun 2006 17:36:36 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7ede4$8r8i0$5@hades.rz.uni-saarland.de>
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 be described
> intentionally? How is "the set of all objects that implement the
> Foo interface" not sufficiently abstract? Is it possible you are
> mixing in implementation concerns?
"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
would be equivalent to some already existent type). So you'd need at
least a theory for name generation or something similar to describe
abstract types in a types-as-sets metaphor.
- Andreas
------------------------------
Date: Thu, 22 Jun 2006 16:02:34 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <uazmg.15709$Z67.12824@tornado.socal.rr.com>
rossberg@ps.uni-sb.de 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 encapsulation as abstraction. I
have any number of old textbooks and journals that refer to these as
"abstract data types", including texts that show an abstract data type
and then explain how to program it as an encapsulated object class.
> No, the following compiles perfectly fine (using GNU Pascal):
That'll teach me to rely on 15-year-old memories. :-) Maybe I'm
remembering the wishful thinking from when I used Pascal.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Thu, 22 Jun 2006 16:06:56 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <Aezmg.15710$Z67.1986@tornado.socal.rr.com>
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)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Thu, 22 Jun 2006 18:05:55 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7ef53$8r8i0$6@hades.rz.uni-saarland.de>
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
-------+-------+----------
safe | ML | Lisp
unsafe | C | Assembler
Now, jargon "dynamically typed" is simply untyped safe, while "weakly
typed" is typed unsafe.
> The real objection to this was that latently/dynamically typed
> languages have a place in it. But some of the advocates of statically
> typed languages wish to lump these languages together with assembly
> language a "untyped" in an attempt to label them as unsafe.
No, see above. And I would assume that that is how most proponents of
the typed/untyped dichotomy understand it.
- Andreas
------------------------------
Date: Thu, 22 Jun 2006 16:29:26 +0000 (UTC)
From: Dimitri Maziuk <dima@127.0.0.1>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <slrne9lhb6.3sv.dima@yellowtail.bmrb.wisc.edu>
George Neuner sez:
> On Wed, 21 Jun 2006 16:12:48 +0000 (UTC), Dimitri Maziuk
><dima@127.0.0.1> wrote:
>
>>George Neuner sez:
>>> On Mon, 19 Jun 2006 22:02:55 +0000 (UTC), Dimitri Maziuk
>>><dima@127.0.0.1> wrote:
>>>
>>>>Yet Another Dan sez:
>>>>
>>>>... Requiring an array index to be an integer is considered a typing
>>>>> problem because it can be checked based on only the variable itself,
>>>>> whereas checking whether it's in bounds requires knowledge about the array.
>>>>
>>>>You mean like
>>>> subtype MyArrayIndexType is INTEGER 7 .. 11
>>>> type MyArrayType is array (MyArrayIndexType) of MyElementType
>>>>
>>>
>>> If the index computation involves wider types it can still produce
>>> illegal index values. The runtime computation of an illegal index
>>> value is not prevented by narrowing subtypes and cannot be statically
>>> checked.
>>
>>My vague recollection is that no, it won't unless _you_ explicitly code an
>>unchecked type conversion. But it's been a while.
>
>
> You can't totally prevent it ... if the index computation involves
> types having a wider range
...
> The point is really that the checks that prevent these things 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 type system that could, a priori, prevent the
> problem is impossible.
Right, but if you look carefully at the paragraph I originally fup'ed
to, you'll notice that it doesn't say "runtime" or "compile-time".
I was commenting on "array bounds not a typing problem" bit -- it is
if you define the index as distinct type, and there is at least one
language that supports it. In this context I don't think it matters
when the check is performed.
It does matter in the larger context of this thread, though. IMO the
important part here is that the crash report clearly points to the
caller code that generated illegal index, not to my library code.
That is the basic argument in favour of compile time error checking,
extended to runtime errors. I don't really care if it's the compiler
or runtime that tells the luser "your code is broken", as long as it
makes it clear it's *his* code that's broken, not mine.
Dima
--
I like the US government, makes the Aussie one look less dumb and THAT is a
pretty big effort. -- Craig Small
------------------------------
Date: Thu, 22 Jun 2006 18:45:22 +0200
From: Pascal Bourguignon <pjb@informatimago.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <87ac859m1p.fsf@thalassa.informatimago.com>
Matthias Blume <find@my.address.elsewhere> writes:
> Pascal Bourguignon <pjb@informatimago.com> 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 function that is able to compare the
>> objects.
>
> Of course, some statically typed languages handle this sort of thing
> routinely.
>
>> Only a few "primitive" functions need specific types.
>
> Your sort function from above also has a specific type -- a type which
> represents the fact that the objects to be sorted must be acceptable
> input to the comparison function.
Well, not exactly. sort is a higher level function. The type of its
arguments is an implicit parameter of the sort function.
(sort "Hello World" (function char<=))
--> " HWdellloor"
(sort '(52 12 42 37) (function <=))
--> (12 37 42 52)
(sort (list (make-instance 'person :name "Pascal")
(make-instance 'unit :name "Pascal")
(make-instance 'programming-language :name "Pascal"))
(lambda (a b) (string<= (class-name (class-of a))
(class-name (class-of b)))))
--> (#<PERSON #x205763FE>
#<PROGRAMMING-LANGUAGE #x205765BE>
#<UNIT #x205764DE>)
In Common Lisp, sort is specified to take a parameter of type SEQUENCE
= (or vector list), and if a list it should be a proper list,
and a function taking two arguments (of any type)
and returning a generalized boolean (that is anything can be returned,
NIL is false, something else is true)
So you could say that:
(sort (sequence element-type)
(function (element-type element-type) boolean))
--> (sequence element-type)
but element-type is not a direct parameter of sort, and can change for
all calls event at the same call point:
(mapcar (lambda (s) (sort s (lambda (a b) (<= (sxhash a) (sxhash b)))))
(list (vector 52 12 42 37)
(list 52 12 42 37)
(list "abc" 'def (make-instance 'person :name "Zorro") 76)))
--> (#(12 37 42 52)
(12 37 42 52)
(76 #<PERSON #x2058D496> DEF "abc"))
>> So basically, you've got a big black box of applicaition code in the
>> middle that doesn't care what type of value they get, and you've got a
>> few input values of a specific type, a few processing functions
>> needing a specific type and returning a specific type, and a few
>> output values that are expected to be of a specific type. At anytime,
>> you may change the type of the input values, and ensure that the
>> needed processing functions will be able to handle this new input
>> type, and the output gets mapped to the expected type.
>
> ...or you type-check your "black box" and make sure that no matter how
> you will ever change the type of the inputs (in accordance with the
> interface type of the box) you get a valid program.
When? At run-time? All the modifications I spoke of can be done at
run-time in Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
------------------------------
Date: Thu, 22 Jun 2006 11:50:53 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1odwlkuc2.fsf@hana.uchicago.edu>
Pascal Bourguignon <pjb@informatimago.com> writes:
> Matthias Blume <find@my.address.elsewhere> writes:
>
>> Pascal Bourguignon <pjb@informatimago.com> 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 function that is able to compare the
>>> objects.
>>
>> Of course, some statically typed languages handle this sort of thing
>> routinely.
>>
>>> Only a few "primitive" functions need specific types.
>>
>> Your sort function from above also has a specific type -- a type which
>> represents the fact that the objects to be sorted must be acceptable
>> input to the comparison function.
>
> Well, not exactly.
What do you mean by "not exactly".
> sort is a higher level function. The type of its
> arguments is an implicit parameter of the sort function.
What do you mean by "higher-level"? Maybe you meant "higher-order" or
"polymorphic"?
[ rest snipped ]
You might want to look up "System F".
>>> So basically, you've got a big black box of applicaition code in the
>>> middle that doesn't care what type of value they get, and you've got a
>>> few input values of a specific type, a few processing functions
>>> needing a specific type and returning a specific type, and a few
>>> output values that are expected to be of a specific type. At anytime,
>>> you may change the type of the input values, and ensure that the
>>> needed processing functions will be able to handle this new input
>>> type, and the output gets mapped to the expected type.
>>
>> ...or you type-check your "black box" and make sure that no matter how
>> you will ever change the type of the inputs (in accordance with the
>> interface type of the box) you get a valid program.
>
> When?
When what?
------------------------------
Date: 22 Jun 2006 09:55:59 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150995359.404878.316920@m73g2000cwd.googlegroups.com>
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 static case is provides you with
a guarantee of type safety, but this is not free, and the
cost of the static case may be evident elsewhere, even
if not illuminated by this example.
Marshall
------------------------------
Date: Thu, 22 Jun 2006 16:24:46 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <449acc54$0$664$bed64819@news.gradwell.net>
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 type theory, aimed
specifically at non-theoreticians."
which was published on/in JoT from:
http://www.jot.fm/issues/issue_2002_05/column5
to
http://www.jot.fm/issues/issue_2005_09/column1
Only 20 episodes ! (But #3 seems to be missing.)
Actually the first one has (in section four) a quick and painless overview of
several kinds of type theory. I haven't read the rest (yet, and maybe never
;-)
-- chris
------------------------------
Date: Thu, 22 Jun 2006 19:02:49 +0200
From: Pascal Bourguignon <pjb@informatimago.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <873bdx9l8m.fsf@thalassa.informatimago.com>
"Marshall" <marshall.spight@gmail.com> 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 guarantee that a and b will always hold numbers.
>
> I still don't really see the difference.
>
> I would not expect that the dynamic programmer will be
> thinking that this code will have two numbers most of the
> time but sometimes not, and fail. I would expect that in both
> static and dynamic, the thought is that that code is adding
> two numbers, with the difference being the static context
> gives one a proof that this is so. 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.
>
> This thread's exploration of the mindset of the two kinds
> of programmers is difficult. It is actually quite difficult,
> (possibly impossible) to reconstruct mental states
> though introspection. Nonetheless I don't see any
> other way to proceed. Pair programming?
Well this is a question of data flow. As I explained, there's a whole
body of functions that don't process concretely the data they get.
But of course, eventually you must write a function that do some
concrete processing on the data it gets. That's when you consider the
type of the values. Such functions may be generic functions with
methods dispatching on the actual type of the parameters, or you may
encounter some TYPECASE or COND inside the function before calling
non-abstract "primitives" that work only on some specific type.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
------------------------------
Date: Thu, 22 Jun 2006 19:21:55 +0200
From: Pascal Bourguignon <pjb@informatimago.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <87y7vp85sc.fsf@thalassa.informatimago.com>
Matthias Blume <find@my.address.elsewhere> writes:
> Pascal Bourguignon <pjb@informatimago.com> writes:
>
>> Matthias Blume <find@my.address.elsewhere> writes:
>>
>>> Pascal Bourguignon <pjb@informatimago.com> 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 function that is able to compare the
>>>> objects.
>>>
>>> Of course, some statically typed languages handle this sort of thing
>>> routinely.
>>>
>>>> Only a few "primitive" functions need specific types.
>>>
>>> Your sort function from above also has a specific type -- a type which
>>> represents the fact that the objects to be sorted must be acceptable
>>> input to the comparison function.
>>
>> Well, not exactly.
>
> What do you mean by "not exactly".
>
>> sort is a higher level function. The type of its
>> arguments is an implicit parameter of the sort function.
>
> What do you mean by "higher-level"? Maybe you meant "higher-order" or
> "polymorphic"?
Yes, that's what I wanted to say.
> [ rest snipped ]
>
> You might want to look up "System F".
> [...]
>>> ...or you type-check your "black box" and make sure that no matter how
>>> you will ever change the type of the inputs (in accordance with the
>>> interface type of the box) you get a valid program.
>>
>> When?
>
> When what?
When will you type-check the "black box"?
A function such as:
(defun f (x y)
(if (g x)
(h x y)
(i y x)))
in the context of a given program could be type-infered statically as
taking an integer and a string as argument. If the compiler did this
inference, it could perhaps generate code specific to these types.
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 "DO-SOMETHING-WITH-A-~A" (type-of x))) x)
(do-something-with-a-string y)))
(funcall (compile nil `(let ((x ,x)) (lambda () (f x "Hi!"))))))
Will you execute the whole type-inference on the whole program "black
box" everytime you define a new function? Will you recompile all the
"black box" functions to take into account the new type the arguments
can be now?
This wouldn't be too efficient. Let's just say that by default, all
arguments and variable are of type T, so the type checking is trivial,
and the generated code is, by default, totally generic.
Only the few concrete, low-level functions need to know the types of
their arguments and variables. In these functions, either the lisp
compiler will do the type inference (starting from the predefined
primitives), or the programmer will declare the types to inform the
compiler what to expect.
(defun do-something-with-a-string (x)
(declare (string x))
...)
(defun do-something-with-a-integer (x)
(declare (integer x))
...)
...
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
------------------------------
Date: 22 Jun 2006 10:43:42 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150998222.352746.65520@i40g2000cwc.googlegroups.com>
Chris Smith wrote:
> Joachim Durchholz <jo@durchholz.org> 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 programs (e.g. by throwing exceptions as
> > appropriate).
>
> So the compiler now attempts to prove theorems about the program, but
> once it has done so it uses the results merely to optimize its runtime
> behavior and then throws the results away. I'd call that not a
> statically typed language, then.
You're assuming that type-correctness is an all-or-nothing property
(well, technically it *is*, but bear with me). What if the compiler is
unable to prove a theorem about the entire program, but *can* prove a
theorem about a subset of the program. The theorems would naturally be
conditional, e.g. `Provided the input is an integer, the program is
type-safe', or time-bounded, e.g. `Until the program attempts to invoke
function FOO, the program is type-safe.'
Of course, we could encode that by restricting the type of the input
and everything would be copacetic, but suppose there is a requirement
that floating point numbers are valid input. For some reason, our
program is not type-safe for floats, but as a developer who is working
on the integer math routines, I have no intention of running that code.
The compiler cannot prove that I won't perversely enter a float, but
it can prove that if I enter an integer everything is type-safe. I can
therefore run, debug, and use a subset of the program.
That's the important point: I want to run broken code. I want to run
as much of the working fragments as I can, and I want a `safety net' to
prevent me from performing undefined operations, but I want the safety
net to catch me at the *last* possible moment. I'm not playing it safe
and staying where the compiler can prove I'll be ok. I'm living
dangerously and wandering near the edge where the compiler can't quite
prove that I'll fail.
Once I've done the major amount of exploratory programming, I may very
well want to tighten things up. I'd like to have the compiler prove
that some mature library is type-safe and that all callers to the
library use it in a type-correct manner. I'd like the compiler to say
`Hey, did you know that if the user enters a floating point number
instead of his name that your program will crash and burn?', but I
don't want that sort of information until I'm pretty sure about what I
want the program to do in the normal case.
------------------------------
Date: Thu, 22 Jun 2006 08:54:18 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: working with perfmon
Message-Id: <220620060854188813%jgibson@mail.arc.nasa.gov>
In article <1150973674.091023.187110@i40g2000cwc.googlegroups.com>,
king <hara.acharya@gmail.com> wrote:
> Hi,
> I am always creating the same perfmon logfile before running any
> knowledge script on daily basis.
> Actually i am running a knowledge script and the same log file of
> perfmon which will create a graph by taking the data from the perfmon
> log file.
> can i automate the creation of log file and the graph of perfmon using
> perl.
>
> Can any body help?
You can use the perl system command to start external programs. See
'perldoc -f system'.
You can use backticks (`program`) or the qx operator (qx(program)) to
run an external program and capture the output from it. See 'perldoc
perlop' and search for "qx".
You can use the open function with pipe (|) to launch an external
program and either send it input or read its output. See 'perldoc -f
open'. To do both input and output, see the IPC::Open2 and IPC::Open3
modules (available from http://www.cpan.org). See also 'perldoc
perlipc'.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9345
***************************************
