[27951] in Perl-Users-Digest
Perl-Users Digest, Issue: 9315 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 19 14:10:14 2006
Date: Mon, 19 Jun 2006 11:10:08 -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 Mon, 19 Jun 2006 Volume: 10 Number: 9315
Today's topics:
Re: What is Expressiveness in a Computer Language <gneuner2/@comcast.net>
Re: What is Expressiveness in a Computer Language (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <gneuner2/@comcast.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
XML Response customizing using PERL <dakanbister@gmail.com>
Re: XML Response customizing using PERL <David.Squire@no.spam.from.here.au>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 19 Jun 2006 06:11:15 -0400
From: George Neuner <gneuner2/@comcast.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <ljsc92dss5t5k43oampeoc6efabu0alsmg@4ax.com>
On 19 Jun 2006 10:19:05 +0200, torbenm@app-3.diku.dk (Torben Ęgidius
Mogensen) wrote:
>If you don't have definitions (stubs or complete) of the functions you
>use in your code, you can only run it up to the point where you call
>an undefined function. So you can't really do much exploration until
>you have some definitions.
Well in Lisp that just drops you into the debugger where you can
supply the needed return data and continue. I agree that it is not
something often needed.
>I expect a lot of the exploration you do with incomplete programs
>amount to the feedback you get from type inference.
The ability to write functions and test them immediately without
writing a lot of supporting code is _far_ more useful to me than type
inference.
I'm not going to weigh in on the static v dynamic argument ... I think
both approaches have their place. I am, however, going to ask what
information you think type inference can provide that substitutes for
algorithm or data structure exploration.
George
--
for email reply remove "/" from address
------------------------------
Date: 19 Jun 2006 13:53:01 +0200
From: torbenm@app-1.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <7z8xnt8iqq.fsf@app-1.diku.dk>
George Neuner <gneuner2/@comcast.net> writes:
> On 19 Jun 2006 10:19:05 +0200, torbenm@app-3.diku.dk (Torben Ęgidius
> Mogensen) wrote:
> >I expect a lot of the exploration you do with incomplete programs
> >amount to the feedback you get from type inference.
>
> The ability to write functions and test them immediately without
> writing a lot of supporting code is _far_ more useful to me than type
> inference.
I can't see what this has to do with static/dynamic typing. You can
test individula functions in isolation is statically typed languages
too.
> I'm not going to weigh in on the static v dynamic argument ... I think
> both approaches have their place. I am, however, going to ask what
> information you think type inference can provide that substitutes for
> algorithm or data structure exploration.
None. But it can provide a framework for both and catch some types of
mistakes early.
Torben
------------------------------
Date: Mon, 19 Jun 2006 09:20:20 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f006ea363b2e2ba9896c4@news.altopia.net>
Torben =C6gidius Mogensen <torbenm@app-3.diku.dk> wrote:
> That's not really the difference between static and dynamic typing.
> Static typing means that there exist a typing at compile-time that
> guarantess against run-time type violations. Dynamic typing means
> that such violations are detected at run-time. This is orthogonal to
> strong versus weak typing, which is about whether such violations are
> detected at all. The archetypal weakly typed language is machine code
> -- you can happily load a floating point value from memory, add it to
> a string pointer and jump to the resulting value. ML and Scheme are
> both strongly typed, but one is statically typed and the other
> dynamically typed.
Knowing that it'll cause a lot of strenuous objection, I'll nevertheless=20
interject my plea not to abuse the word "type" with a phrase like=20
"dynamically typed". If anyone considers "untyped" to be perjorative,=20
as some people apparently do, then I'll note that another common term is=20
"type-free," which is marketing-approved but doesn't carry the=20
misleading connotations of "dynamically typed." We are quickly losing=20
any rational meaning whatsoever to the word "type," and that's quite a=20
shame.
By way of extending the point, let me mention that there is no such=20
thing as a universal class of things that are called "run-time type=20
violations". At runtime, there is merely correct code and incorrect=20
code. To the extent that anything is called a "type" at runtime, this=20
is a different usage of the word from the usage by which we may define=20
languages as being statically typed (which means just "typed"). In=20
typed OO languages, this runtime usage is often called the "class", for=20
example, to distinguish it from type.
This cleaner terminology eliminates a lot of confusion. For example, it=20
clarifies that there is no binary division between strongly typed=20
languages and weakly typed languages, since the division between a "type=20
error" and any other kind of error is arbitrary, depending only on=20
whether the type system in a particular language happens to catch that=20
error. For example, type systems have been defined to try to catch unit=20
errors in scientific programming, or to catch out-of-bounds array=20
indices... yet these are not commonly called "type errors" only because=20
such systems are not in common use.
This also leads us to define something like "language safety" to=20
encapsulate what we previously would have meant by the phrase "strongly=20
dynamically typed language". This also is a more general concept than=20
we had before. Language safety refers to a language having well-defined=20
behavior for as many operations as feasible, so that it's less likely=20
that someone will do something spectacularly bad. Language safety may=20
be achieved either by a type system or by runtime checks. Again, it's=20
not absolute... I'm aware of no language that is completely determinate,=20
at least if it supports any kind of concurrency.
This isn't just a matter of preference in terminology. The definitions=20
above (which are, in my experience, used widely by most non-academic=20
language design discussions) actually limit our understanding of=20
language design by pretending that certain delicate trade-offs such as=20
the extent of the type system, or which language behavior is allowed to=20
be non-deterministic or undefined, are etched in stone. This is simply=20
not so. If types DON'T mean a compile-time method for proving the=20
absence of certain program behaviors, then they don't mean anything at=20
all. Pretending that there's a distinction at runtime between "type=20
errors" and "other errors" serves only to confuse things and=20
artificially limit which problems we are willing to concieve as being=20
solvable by types.
> Anyway, type inference for statically typed langauges don't make them
> any more dynamically typed.
Indeed it does not. Unless it weakens the ability of a compiler to=20
prove the absence of certain program behaviors (which type inference=20
does not), it doesn't move anything on the scale toward a type-free=20
language.
That being said, though, it is considered a feature of some programming=20
languages that the programmer is asked to repeat type information in a=20
few places. The compiler may not need the information, but for=20
precisely the reason that the information is redundant, the compiler is=20
then able to check the consistency of the programmer in applying the=20
type. I won't get into precisely how useful this is, but it is=20
nevertheless present as an advantage to outweigh the wordiness.
--=20
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 19 Jun 2006 08:44:49 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150731889.008745.12180@i40g2000cwc.googlegroups.com>
Chris Smith wrote:
> Torben =C6gidius Mogensen <torbenm@app-3.diku.dk> wrote:
> > That's not really the difference between static and dynamic typing.
> > Static typing means that there exist a typing at compile-time that
> > guarantess against run-time type violations. Dynamic typing means
> > that such violations are detected at run-time. This is orthogonal to
> > strong versus weak typing, which is about whether such violations are
> > detected at all. The archetypal weakly typed language is machine code
> > -- you can happily load a floating point value from memory, add it to
> > a string pointer and jump to the resulting value. ML and Scheme are
> > both strongly typed, but one is statically typed and the other
> > dynamically typed.
>
> Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
> interject my plea not to abuse the word "type" with a phrase like
> "dynamically typed". If anyone considers "untyped" to be perjorative,
> as some people apparently do, then I'll note that another common term is
> "type-free," which is marketing-approved but doesn't carry the
> misleading connotations of "dynamically typed." We are quickly losing
> any rational meaning whatsoever to the word "type," and that's quite a
> shame.
I don't think dynamic typing is that nebulous. I remember this being
discussed elsewhere some time ago, I'll post the same reply I did then
.=2E
A language is statically typed if a variable 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.
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.
Some people use dynamic typing as a word for latent typing, others use
it to mean something slightly different. But for most purposes the
definition above works for dynamic typing also.
Untyped and type-free mean something else: they mean no type checking
is done.
------------------------------
Date: Mon, 19 Jun 2006 18:22:02 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fo19aF1jsudeU1@individual.net>
Chris Smith wrote:
> Torben Ęgidius Mogensen <torbenm@app-3.diku.dk> wrote:
>> That's not really the difference between static and dynamic typing.
>> Static typing means that there exist a typing at compile-time that
>> guarantess against run-time type violations. Dynamic typing means
>> that such violations are detected at run-time. This is orthogonal to
>> strong versus weak typing, which is about whether such violations are
>> detected at all. The archetypal weakly typed language is machine code
>> -- you can happily load a floating point value from memory, add it to
>> a string pointer and jump to the resulting value. ML and Scheme are
>> both strongly typed, but one is statically typed and the other
>> dynamically typed.
>
> Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
> interject my plea not to abuse the word "type" with a phrase like
> "dynamically typed". If anyone considers "untyped" to be perjorative,
> as some people apparently do, then I'll note that another common term is
> "type-free," which is marketing-approved but doesn't carry the
> misleading connotations of "dynamically typed." We are quickly losing
> any rational meaning whatsoever to the word "type," and that's quite a
> shame.
The words "untyped" or "type-free" only make sense in a purely
statically typed setting. In a dynamically typed setting, they are
meaningless, in the sense that there are _of course_ types that the
runtime system respects.
Types can be represented at runtime via type tags. You could insist on
using the term "dynamically tagged languages", but this wouldn't change
a lot. Exactly _because_ it doesn't make sense in a statically typed
setting, the term "dynamically typed language" is good enough to
communicate what we are talking about - i.e. not (static) typing.
> By way of extending the point, let me mention that there is no such
> thing as a universal class of things that are called "run-time type
> violations". At runtime, there is merely correct code and incorrect
> code.
No, there is more: There is safe and unsafe code (i.e., code that throws
exceptions or that potentially just does random things). There are also
runtime systems where you have the chance to fix the reason that caused
the exception and continue to run your program. The latter play very
well with dynamic types / type tags.
> To the extent that anything is called a "type" at runtime, this
> is a different usage of the word from the usage by which we may define
> languages as being statically typed (which means just "typed"). In
> typed OO languages, this runtime usage is often called the "class", for
> example, to distinguish it from type.
What type of person are you to tell other people what terminology to use? ;)
Ha! Here I used "type" in just another sense of the word. ;)
It is important to know the context in which you are discussing things.
For example, "we" Common Lispers use the term "type" as defined in
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_t.htm . You
cannot possibly argue that "our" use of the word "type" is incorrect
because in "our" context, when we talk about Common Lisp, the use of the
word "type" better be consistent with that definition. (You can say that
you don't like the definition, that it is unsound, or whatever, but that
doesn't change anything here.)
> This cleaner terminology eliminates a lot of confusion. For example, it
> clarifies that there is no binary division between strongly typed
> languages and weakly typed languages, since the division between a "type
> error" and any other kind of error is arbitrary, depending only on
> whether the type system in a particular language happens to catch that
> error. For example, type systems have been defined to try to catch unit
> errors in scientific programming, or to catch out-of-bounds array
> indices... yet these are not commonly called "type errors" only because
> such systems are not in common use.
What type system catches division by zero? That is, statically? Would
you like to program in such a language?
> This isn't just a matter of preference in terminology. The definitions
> above (which are, in my experience, used widely by most non-academic
> language design discussions) actually limit our understanding of
> language design by pretending that certain delicate trade-offs such as
> the extent of the type system, or which language behavior is allowed to
> be non-deterministic or undefined, are etched in stone. This is simply
> not so. If types DON'T mean a compile-time method for proving the
> absence of certain program behaviors, then they don't mean anything at
> all. Pretending that there's a distinction at runtime between "type
> errors" and "other errors" serves only to confuse things and
> artificially limit which problems we are willing to concieve as being
> solvable by types.
Your problem doesn't exist. Just say "types" when you're amongst your
own folks, and "static types" when you're amongst a broader audience,
and everything's fine. Instead of focusing on terminology, just focus on
the contents.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Mon, 19 Jun 2006 10:31:55 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f007f6a483b5e7d9896c6@news.altopia.net>
Rob Thorpe <robert.thorpe@antenova.com> 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.
I'm assuming you mean "class" in the general sense, rather than in the
sense of a specific construct of some subset of OO programming
languages.
Now I define a class of values called "correct" values. I define these
to be those values for which my program will produce acceptable results.
Clearly there is a defined class of such values: (1) they are
immediately defined by the program's specification for those lines of
code that produce output; (2) if they are defined for the values that
result from any expression, then they are defined for the values that
are used by that expression; and (3) for any value for which correctness
is not defined by (1) or (2), we may define its "correct" values as the
class of all possible values. Now, by your definition, any language
which provides checking of that property of correctness for values is
latently typed. Of course, there are no languages that assign this
specific class of values; but ANY kind of correctness checking on values
that a language does (if it's useful at all) is a subset of the perfect
correctness checking system above. Apparently, we should call all such
systems "latent type systems". Can you point out a language that is not
latently typed?
I'm not trying to poke holes in your definition for fun. I am proposing
that there is no fundamental distinction between the kinds of problems
that are "type problems" and those that are not. Types are not a class
of problems; they are a class of solutions. Languages that solve
problems in ways that don't assign types to variables are not typed
languages, even if those same problems may have been originally solved
by type systems.
> Untyped and type-free mean something else: they mean no type checking
> is done.
Hence, they don't exist, and the definitions being used here are rather
pointless.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 19 Jun 2006 13:33:23 -0400
From: George Neuner <gneuner2/@comcast.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <jfnd92dim5qg3eq4fh10rvdncpdida29c5@4ax.com>
On 19 Jun 2006 13:53:01 +0200, torbenm@app-1.diku.dk (Torben Ęgidius
Mogensen) wrote:
>George Neuner <gneuner2/@comcast.net> writes:
>
>> On 19 Jun 2006 10:19:05 +0200, torbenm@app-3.diku.dk (Torben Ęgidius
>> Mogensen) wrote:
>
>> >I expect a lot of the exploration you do with incomplete programs
>> >amount to the feedback you get from type inference.
>>
>> The ability to write functions and test them immediately without
>> writing a lot of supporting code is _far_ more useful to me than type
>> inference.
>
>I can't see what this has to do with static/dynamic typing. You can
>test individul functions in isolation is statically typed languages
>too.
It has nothing to do with static/dynamic typing and that was the point
... that support for exploratory programming is orthogonal to the
language's typing scheme.
George
--
for email reply remove "/" from address
------------------------------
Date: Mon, 19 Jun 2006 11:57:08 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0093611056cbb19896c7@news.altopia.net>
Pascal Costanza <pc@p-cos.net> wrote:
> Types can be represented at runtime via type tags. You could insist on
> using the term "dynamically tagged languages", but this wouldn't change
> a lot. Exactly _because_ it doesn't make sense in a statically typed
> setting, the term "dynamically typed language" is good enough to
> communicate what we are talking about - i.e. not (static) typing.
Okay, fair enough. It's certainly possible to use the same sequence of
letters to mean two different things in different contexts. The problem
arises, then, when Torben writes:
: That's not really the difference between static and dynamic typing.
: Static typing means that there exist a typing at compile-time that
: guarantess against run-time type violations. Dynamic typing means
: that such violations are detected at run-time.
This is clearly not using the word "type" to mean two different things
in different contexts. Rather, it is speaking under the mistaken
impression that "static typing" and "dynamic typing" are varieties of
some general thing called "typing." In fact, the phrase "dynamically
typed" was invented to do precisely that. My argument is not really
with LISP programmers talking about types, by which they would mean
approximately the same thing Java programmers mean by "class." My point
here concerns the confusion that results from the conception that there
is this binary distinction (or continuum, or any other simple
relationship) between a "statically typed" and a "dynamically typed"
language.
Torben's (and I don't mean to single out Torben -- the terminology is
used quite widely) classification of dynamic versus static type systems
depends on the misconception that there is some universal definition to
the term "type error" or "type violation" and that the only question is
how we address these well-defined things. It's that misconception that
I aim to challenge.
> No, there is more: There is safe and unsafe code (i.e., code that throws
> exceptions or that potentially just does random things). There are also
> runtime systems where you have the chance to fix the reason that caused
> the exception and continue to run your program. The latter play very
> well with dynamic types / type tags.
Yes, I was oversimplifying.
> What type system catches division by zero? That is, statically?
I can define such a type system trivially. To do so, I simply define a
type for integers, Z, and a subtype for non-zero integers, Z'. I then
define the language such that division is only possible in an expression
that looks like << z / z' >>, where z has type Z and z' has type Z'.
The language may then contain an expression:
z 0? t1 : t2
in which t1 is evaluated in the parent type environment, but t2 is
evaluated in the type environment augmented by (z -> Z'), the type of
the expression is the intersection type of t1 and t2 evaluated in those
type environments, and the evaluation rules are defined as you probably
expect.
> Would you like to program in such a language?
No. Type systems for real programming languages are, of course, a
balance between rigor and usability. This particular set of type rules
doesn't seem to exhibit a good balance. Perhaps there is a way to
achieve it in a way that is more workable, but it's not immediately
obvious.
As another example, from Pierce's text "Types and Programming
Languages", Pierce writes: "Static elimination of array-bounds checking
is a long-standing goal for type system designers. In principle, the
necessary mechanisms (based on dependent types) are well understood, but
packaging them in a form that balances expressive power, predictability
and tractability of typechecking, and complexity of program annotations
remains a significant challenge." Again, this could quite validly be
described as a type error, just like division by zero or ANY other
program error... it's just that the type system that solves it doesn't
look appealing, so everyone punts the job to runtime checks (or, in some
cases, to the CPU's memory protection features and/or the user's ability
to fix resulting data corruption).
Why aren't these things commonly considered type errors? There is only
one reason: there exists no widely used language which solves them with
types. (I mean in the programming language type theory sense of "type";
since many languages "tag" arrays with annotations indicating their
dimensions, I guess you could say that we do solve them with types in
the LISP sense).
> Your problem doesn't exist. Just say "types" when you're amongst your
> own folks, and "static types" when you're amongst a broader audience,
> and everything's fine.
I think I've explained why that's not the case. I don't have a
complaint about anyone speaking of types. It's the confusion from
pretending that the two definitions are comparable that I'm pointing
out.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 19 Jun 2006 10:41:00 -0700
From: "dexteru2" <dakanbister@gmail.com>
Subject: XML Response customizing using PERL
Message-Id: <1150738860.609977.55980@r2g2000cwb.googlegroups.com>
Hello All,
Please can someone assist me on how to customize the output of XML
response using perl.
For example i have an output like this
......
<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>originHostName</name>
<value>
<string>WEB_HOST</string>
</value>
</member>
.......
.......
</member>
</struct>
</value>
</param>
</params>
</methodResponse>
But i want the output to be like ;
The hostname is WEB_HOST...And not in the default form as above.
Regards
------------------------------
Date: Mon, 19 Jun 2006 18:45:53 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: XML Response customizing using PERL
Message-Id: <e76nsh$b9s$1@news.ox.ac.uk>
dexteru2 wrote:
> Hello All,
> Please can someone assist me on how to customize the output of XML
> response using perl.
>
Go to CPAN and search for XML. There are many modules out there that can
help you... for example XML::Writer.
DS
------------------------------
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 9315
***************************************
