[27984] in Perl-Users-Digest
Perl-Users Digest, Issue: 9348 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 22 21:05:34 2006
Date: Thu, 22 Jun 2006 18:05:03 -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: 9348
Today's topics:
Re: Binding array to pattern <tadmc@augustmail.com>
Re: Getting Real IP Behind Proxy <hjp-usenet2@hjp.at>
Re: question on Net::LPR / Unix::Login <wblock@wonkity.com>
Unwanted character "^@" in perl output <kvfloyd@cableone.net>
Re: Unwanted character "^@" in perl output <hoosier45678@hotmail.com>
Re: Unwanted character "^@" in perl output <hoosier45678@hotmail.com>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Re: What is Expressiveness in a Computer Language <anton@appsolutions.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Jun 2006 19:41:53 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Binding array to pattern
Message-Id: <slrne9me6h.5tf.tadmc@magna.augustmail.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <slrne9jg9k.uog.tadmc@magna.augustmail.com>, on 06/21/2006
> at 04:59 PM, Tad McClellan <tadmc@augustmail.com> said:
>
>>What bug was that?
>
> The one that exists in the real world, not just in your imagination.
We did not know the "real world" when I pointed out that bug
because you didn't give a complete enough specification.
At that point all we had was /pattern/, so we did not know that
your pattern did not contain spaces.
>>The bug of matching across element boundaries?
>
> There is no "bug of matching across element boundaries" in the code,
There is if there is a space in /pattern/
>>Go read what he said again.
>
> You mean "(though I suspect this isn't an issue in your case)."?
Because by then you had revealed what "your case" was. That had
not yet been revealed when I pointed out a bug. I cannot see
the future.
>>And it is the same bug that I had already pointed out anyway.
>
> Yes, the same imaginary bug that you invented the first time.
It was not imaginary, it was entirely possible with the information
that was available at the time I wrote it.
>>I provided code showing the bug in your approach,
>
> No you didn't. You provided code that had nothing to do with my
> approach.
Your approach was to concatenate all of the elements together,
and add a space character between each element.
The code I provided to demonstrate the bug used that same approach.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 23 Jun 2006 00:11:29 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Getting Real IP Behind Proxy
Message-Id: <hi4f7e.k6v.ln@teal.hjp.at>
M wrote:
> I have a perl script that runs on a webserver. When someone calls this
> script I want to determine there IP address. Currently I use
> "$ENV{'REMOTE_ADDR'};" for this. Problem is many users connect through a
> proxy cache wether they know it or not so the script sees there proxies IP
> and not there own. Is there any easy way to get there real IP?
Many proxies include the IP address of the client in an X-Forwarded-For
header (The proxy should note its own address in a Via header). Please
note that this header is non-standard (although common), that some
proxies lie about their clients address, and even if you get the real
address, it may be unusable because it is a private address.
And as Brian already said, this doesn't help you for NATted networks.
So the real question is: What do you want to do with this information?
hp
--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | hjp@hjp.at | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15
------------------------------
Date: Thu, 22 Jun 2006 23:22:00 -0000
From: Warren Block <wblock@wonkity.com>
Subject: Re: question on Net::LPR / Unix::Login
Message-Id: <slrne9m9gn.1kug.wblock@speedy.wonkity.com>
Huub <"v.niekerk at hccnet.nl"> wrote:
> > Show us how you're sending the information to lpr.
>
> use Net::LPR;
>
> my $lp = new Net::LPR (
> StrictRFCPorts => 1,
> RemoteServer => '10.0.0.2 DeskJet520',
^^^^^^^^^^^
That doesn't look right. Try it with just the IP address or hostname,
but not both.
If the local system has a printcap definition for that printer, you
could just open a pipe to lpr and write the data there.
--
Warren Block * Rapid City, South Dakota * USA
------------------------------
Date: 22 Jun 2006 16:06:44 -0700
From: "Captain 3-Putt" <kvfloyd@cableone.net>
Subject: Unwanted character "^@" in perl output
Message-Id: <1151017604.335023.323930@c74g2000cwc.googlegroups.com>
My output has a bunch of unwanted "^@" characters after every valid
character. It looks like:
^@F^@i^@r^@s^@t^@^M^@
I want it to look like:
First^M
vim's 'g', 'a' shows "<^@> 0, Hex 00, Octal 000"
It's just a null character?? How do I get rid of it?
Thanks!
Ken
----------------------------------
#!/usr/bin/perl
open(BBOARD_DOWN, "<$ARGV[0]") or die ("Couldn't open $ARGV[0]");
@file=<BBOARD_DOWN>;
close(BBOARD_DOWN);
$header = $file[0];
for ($i = 1; $i <= $#file; ++$i) {
$student[$i] = $file[$i];
}
# student records, one at a time
@field = split(/\t/, $header);
for ($i = 0; $i <= $#field; ++$i) {
print "$field[$i]\t";
}
for ($i = 1; $i <= $#file; ++$i) {
print $student[$i];
}
------------------------------
Date: Thu, 22 Jun 2006 18:24:05 -0500
From: James <hoosier45678@hotmail.com>
Subject: Re: Unwanted character "^@" in perl output
Message-Id: <pan.2006.06.22.23.23.59.332920@hotmail.com>
On Thu, 22 Jun 2006 16:06:44 -0700, Captain 3-Putt wrote:
> My output has a bunch of unwanted "^@" characters after every valid
> character. It looks like:
>
> ^@F^@i^@r^@s^@t^@^M^@
>
> I want it to look like:
>
> First^M
>
> vim's 'g', 'a' shows "<^@> 0, Hex 00, Octal 000"
>
> It's just a null character?? How do I get rid of it?
>
> Thanks!
>
> Ken
utf-16, perhaps? I used iconv to strip the 0's from an itunes playlist
export, but to do things right you'll probably want to look into
Unicode::String or similar, especially if it's not all /(0.)*/
------------------------------
Date: Thu, 22 Jun 2006 18:30:48 -0500
From: James <hoosier45678@hotmail.com>
Subject: Re: Unwanted character "^@" in perl output
Message-Id: <pan.2006.06.22.23.30.42.759015@hotmail.com>
On Thu, 22 Jun 2006 18:24:05 -0500, I wrote:
>
> utf-16, perhaps? I used iconv to strip the 0's from an itunes playlist
> export, but to do things right you'll probably want to look into
> Unicode::String or similar, especially if it's not all /(0.)*/
err... /(\0.)*/
and see this:
http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlunicode.pod
------------------------------
Date: Thu, 22 Jun 2006 22:08:14 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <ixEmg.55552$Lm5.50067@newssvr12.news.prodigy.com>
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.)
The short answer is that I'm most directly referring to "the types in
the programmer's head". A more complete informal summary is as follows:
Languages with latent type systems typically don't include type
declarations in the source code of programs. The "static" type scheme
of a given program in such a language is thus latent, in the English
dictionary sense of the word, of something that is present but
undeveloped. Terms in the program may be considered as having static
types, and it is possible to infer those types, but it isn't necessarily
easy to do so automatically, and there are usually many possible static
type schemes that can be assigned to a given program.
Programmers infer and reason about these latent types while they're
writing or reading programs. Latent types become manifest when a
programmer reasons about them, or documents them e.g. in comments.
(As has already been noted, this definition may seem at odds with the
definition given in the Scheme report, R5RS, but I'll address that in a
separate post.)
There's a close connection between latent types in the sense I've
described, and the "tagged values" present at runtime. However, as type
theorists will tell you, the tags used to tag values at runtime, as e.g.
a number or a string or a FooBar object, are not the same thing as the
sort of types which statically-typed languages have.
A simple example of the distinction can be seen in the type of a
function. Using Javascript as a lingua franca:
function timestwo(x) { return x * 2 }
In a statically-typed language, the type of a function like this might
be something like "number -> number", which tells us three things: that
timestwo is a function; that it accepts a number argument; and that it
returns a number result.
But if we ask Javascript what it thinks the type of timestwo is, by
evaluating "typeof timestwo", it returns "function". That's because the
value bound to timestwo has a tag associated with it which says, in
effect, "this value is a function".
But "function" is not a useful type. Why not? Because if all you know
is that timestwo is a function, then you have no idea what an expression
like "timestwo(foo)" means. You couldn't write working programs, or
read them, if all you knew about functions was that they were functions.
As a type, "function" is incomplete.
By my definition, though, the latent type of timestwo is "number ->
number". Any programmer looking at the function can figure out that
this is its type, and programmers do exactly that when reasoning about a
program.
(Aside: technically, you can pass timestwo something other than a
number, but then you get NaN back, which is usually not much use except
to generate errors. I'll ignore that here; latent typing requires being
less rigourous about some of these issues.)
So, where do tagged values fit into this? Tags help to check types at
runtime, but that doesn't mean that there's a 1:1 correspondence between
tags and types. For example, when an expression such as "timestwo(5) *
3" is evaluated, three checks occur that are relevant to the type of
timestwo:
1. Before the function call takes place, a check ensures that timestwo
is a function.
2. Before the multiplication in "x * 2", a check ensures that x is a number.
3. When timestwo returns, before the subsequent multiplication by 3, a
check ensures that the return type of timestwo is a number.
These three checks correspond to the three pieces of information
contained in the function type signature "number -> number".
However, these dynamic checks still don't actually tell us the type of a
function. All they do is check that in a particular case, the values
involved are compatible with the type of the function. In many cases,
the checks may infer a signature that's either more or less specific
than the function's type, or they may infer an incomplete signature --
e.g., the return type doesn't need to be checked when evaluating "arr[i]
= timestwo(5)".
I used a function just as an example. There are many other cases where
a value's tag doesn't match the static (or latent) type of the terms
through which it flows. A simple example is an expression such as:
(flag ? 5 : "foo")
Here, the latent type of this expression could be described as "number |
string". There won't be a runtime tag anywhere which represents that
type, though, since the language implementation never deals with the
actual type of expressions, except in those degenerate cases where the
type is so simple that it happens to be a 1:1 match to the corresponding
tag. It's only the programmer that "knows" that this expression has
that type.
Anton
------------------------------
Date: Thu, 22 Jun 2006 22:17:37 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <5GEmg.208020$8W1.13213@fe1.news.blueyonder.co.uk>
Pascal Bourguignon wrote:
> Pascal Costanza <pc@p-cos.net> 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
>>>>additionally need to know that there must a guarantee that a and b
>>>>will always hold numbers.
>>>
>>>I'm confused. Are you telling that you just write a+b in your
>>>programs without trying to ensure that a and b are in fact numbers??
>>
>>Basically, yes.
>>
>>Note that this is a simplistic example. Consider, instead, sending a
>>message to an object, or calling a generic function, without ensuring
>>that there will be applicable methods for all possible cases. When I
>>get a "message not understood" exception, I can then decide whether
>>that kind of object shouldn't be a receiver in the first place, or
>>else whether I should define an appropriate method. I don't want to be
>>forced to decide this upfront, because either I don't want to be
>>bothered, or maybe I simply can't because I don't understand the
>>domain well enough yet, or maybe I want to keep a hook to be able to
>>update the program appropriately while it is running.
>
> 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.
But this is true also in a statically typed language with parametric
polymorphism.
[...]
> Why should adding a few functions or methods, and providing input
> values of a new type be rejected from a statically checked point of
> view by a compiled program that would be mostly bit-for-bit the same
> with or without this new type?
It usually wouldn't be -- adding methods in a typical statically typed
OO language is unlikely to cause type errors (unless there is a naming
conflict, in some cases). Nor would adding new types or new functions.
(*Using* new methods without declaring them would cause an error, yes.)
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Thu, 22 Jun 2006 22:27:09 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1PEmg.472643$xt.199547@fe3.news.blueyonder.co.uk>
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 "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?
Yes, why not?
> This wouldn't be too efficient.
It's rare, so it doesn't need to be efficient. 'eval' is inherently
inefficient, anyway.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Thu, 22 Jun 2006 22:46:02 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <K4Fmg.208022$8W1.205835@fe1.news.blueyonder.co.uk>
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 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.
Set theory has no difficulty with this. It's common, for example, to see
"the set of strings representing propositions" used in treatments of
formal systems.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Thu, 22 Jun 2006 23:32:19 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <7MFmg.27168$VE1.8188@newssvr14.news.prodigy.com>
Vesa Karvonen wrote:
> In comp.lang.functional Anton van Straaten <anton@appsolutions.com> 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" is a synonym for having
> "well-defined semantics" or being "safe" and therefore feel the need
> to be able to speak of their language as "typed" whether or not it
> makes sense.
I reject this comparison. There's much more to it than that. The point
is that the reasoning which programmers perform when working with an
program in a latently-typed language bears many close similiarities to
the purpose and behavior of type systems.
This isn't an attempt to jump on any bandwagons, it's an attempt to
characterize what is actually happening in real programs and with real
programmers. I'm relating that activity to type systems because that is
what it most closely relates to.
Usually, formal type theory ignores such things, because of course
what's in the programmer's head is outside the domain of the formal
definition of an untyped language. But all that means is that formal
type theory can't account for the entirety of what's happening in the
case of programs in untyped languages.
Unless you can provide some alternate theory of the subject that's
better than what I'm offering, it's not sufficient to complain "but that
goes beyond (static/syntactic) type theory". Yes, it goes beyond
traditional type theory, because it's addressing with something which
traditional type theory doesn't address. There are reasons to connect
it to type theory, and if you can't see those reasons, you need to be
more explicit about why.
> I agree. I think that instead of "statically typed" we should say
> "typed" and instead of "(dynamically|latently) typed" we should say
> "untyped".
The problem with "untyped" is that there are obvious differences in
typing behavior between the untyped lambda calculus and, say, a language
like Scheme (and many others). Like all latently-typed languages,
Scheme includes, in the language, mechanisms to tag values in a way that
supports checks which help the programmer to ensure that the program's
behavior matches the latent type scheme that the programmer has in mind.
See my other recent reply to Marshall for a more detailed explanation
of what I mean.
I'm suggesting that if a language classifies and tags values in a way
that supports the programmer in static reasoning about the behavior of
terms, that calling it "untyped" does not capture the entire picture,
even if it's technically accurate in a restricted sense (i.e. in the
sense that terms don't have static types that are known within the
language).
Let me come at this from another direction: what do you call the
classifications into number, string, vector etc. that a language like
Scheme does? And when someone writes a program which includes the
following lines, how would you characterize the contents of the comment:
; third : integer -> integer
(define (third n) (quotient n 3))
In my experience, answering these questions without using the word
"type" results in a lot of silliness. And if you do use "type", then
you're going to have to adjust the rest of your position significantly.
>>In a statically-checked language, people tend to confuse automated
>>static checking with the existence of types, because they're thinking in
>>a strictly formal sense: they're restricting their world view to what
>>they see "within" the language.
>
>
> That is not unreasonable. You see, you can't have types unless you
> have a type system. Types without a type system are like answers
> without questions - it just doesn't make any sense.
The first point I was making is that *automated* checking has very
little to do with anything, and conflating static types with automated
checking tends to lead to a lot of confusion on both sides of the
static/dynamic fence.
But as to your point, latently typed languages have informal type
systems. Show me a latently typed language or program, and I can tell
you a lot about its type system or type scheme.
Soft type inferencers demonstrate this by actually defining a type
system and inferring type schemes for programs. That's a challenging
thing for an automated tool to do, but programmers routinely perform the
same sort of activity on an informal basis.
>>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 may be
>>messy compared to say an HM type scheme, and it's usually not proved to
>>be perfect, but that again is an orthogonal issue.
>
>
> There is a huge hole in your argument above. Types really do not make
> sense without a type system. To claim that a program has a type
> scheme, you must first specify the type system. Otherwise it just
> doesn't make any sense.
Again, the type system is informal. What you're essentially saying is
that only things that are formally defined make sense. But you can't
wish dynamically-checked languages out of existence. So again, how
would you characterize these issues in dynamically-checked languages?
Saying that it's just a matter of well-defined semantics doesn't do
anything to address the details of what's going on. I'm asking for a
more specific account than that.
>>Mathematicians operated for thousands of years without automated
>>checking of proofs, so you can't argue that because a
>>dynamically-checked program hasn't had its type scheme proved correct,
>>that it somehow doesn't have types. That would be a bit like arguing
>>that we didn't have Math until automated theorem provers came along.
>
>
> No - not at all. First of all, mathematics has matured quite a bit
> since the early days. I'm sure you've heard of the axiomatic method.
> However, what you are missing is that to prove that your program has
> types, you first need to specify a type system. Similarly, to prove
> something in math you start by specifying [fill in the rest].
I agree, to make the comparison perfect, you'd need to define a type
system. But that's been done in various cases. So is your complaint
simply that most programmers are working with informal type systems?
I've already stipulated that.
However, I think that you want to suggest that those programmers are not
working with type systems at all.
This reminds me of a comedy skit which parodied the transparency of
Superman's secret identity: Clark Kent is standing in front of Lois Lane
and removes his glasses for some reason. Lois looks confused and says
"where did Clark go?" Clark quickly puts his glasses back on, and Lois
breathes a sigh of relief, "Oh, there you are, Clark".
The problem we're dealing with in this case is that anything that's not
formally defined is essentially claimed to not exist. It's lucky that
this isn't really the case, otherwise much of the world around us would
vanish in a puff of formalist skepticism.
We're discussing systems that operate on an informal basis: in this
case, the reasoning about the classification of values which flow
through terms in a dynamically-checked language. If you can produce a
useful formal model of those systems that doesn't omit significant
information, that's great, and I'm all ears.
However, claiming that e.g. using a universal type is a complete model
what's happening misses the point: it doesn't account at all for the
reasoning process I've just described.
>>1. "Untyped" is really quite a misleading term, unless you're talking
>>about something like the untyped lambda calculus. That, I will agree,
>>can reasonably be called untyped.
>
>
> Untyped is not misleading. "Typed" is not a synonym for "safe" or
> "having well-defined semantics".
Again, your two suggested replacements don't come close to capturing
what I'm talking about. Without better alternatives, "type" is the
closest appropriate term. I'm qualifying it with the term "latent",
precisely to indicate that I'm not talking about formally-defined types.
I'm open to alternative terminology or ways of characterizing this, but
they need to address issues that exist outside the boundaries of formal
type systems, so simply applying terms from formal type theory is not
usually sufficient.
>>So, will y'all just switch from using "dynamically typed" to "latently
>>typed"
>
>
> I won't (use "latently typed"). At least not without further
> qualification.
This and my other recent post give a fair amount of qualification, so
let me know if you need anything else to be convinced. :)
But to be fair, I'll start using "untyped" if you can come up with a
satisfactory answer to the two questions I asked above, just before I
used the word "silliness".
Anton
------------------------------
Date: Thu, 22 Jun 2006 23:50:26 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <61Gmg.27175$VE1.20@newssvr14.news.prodigy.com>
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 think you'll find it'll help to reason more clearly about this
>>whole issue.
>
>
> I agree with most of what you say except regarding "untyped".
>
> In machine language or most assembly the type of a variable is
> something held only in the mind of the programmer writing it, and
> nowhere else. In latently typed languages though the programmer can
> ask what they type of a particular value is. There is a vast
> difference to writing code in the latter kind of language to writing
> code in assembly.
The distinction you describe is pretty much exactly what I was getting
at. I may have put it poorly.
> I would suggest that at least assembly should be referred to as
> "untyped".
Yes, I agree.
While we're talking about "untyped", I want to expand on something I
wrote in a recent reply to Vesa Karvonen: I accept that "untyped" has a
technical definition which means that a language doesn't statically
assign types to terms. But this doesn't capture the distinction between
"truly" untyped languages, and languages which tag their values to
support the programmer's ability to think in terms of latent types.
The point of avoiding the "untyped" label is not because it's not
technically accurate (in a limited sense) -- it's because in the absence
of other information, it misses out on important aspects of the nature
of latently typed languages. My reply to Vesa goes into more detail
about this.
Anton
------------------------------
Date: Fri, 23 Jun 2006 00:54:13 GMT
From: Anton van Straaten <anton@appsolutions.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <VYGmg.27606$VE1.2542@newssvr14.news.prodigy.com>
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 called objects) rather than with variables.
>> (Some authors refer to languages with latent types as weakly typed
>> or dynamically typed languages.) Other languages with latent types
>> are APL, Snobol, and other dialects of Lisp. Languages with manifest
>> types (sometimes referred to as strongly typed or statically typed
>> languages) include Algol 60, Pascal, and C.
>
>
> Maybe this is the original source of the myth that static typing is all
> about assigning types to variables...
>
> With all my respect to the Scheme people, I'm afraid this paragraph is
> pretty off, no matter where you stand. Besides the issue just mentioned
> it equates "manifest" with static types. I understand "manifest" to mean
> "explicit in code", which of course is nonsense - static typing does not
> require explicit types. Also, I never heard "weakly typed" used in the
> way they suggest - in my book, C is a weakly typed language (= typed,
> but grossly unsound).
That text goes back at least 20 years, to R3RS in 1986, and possibly
earlier, so part of what it represents is simply changing use of
terminology, combined with an attempt to put Scheme in context relative
to multiple languages and terminology usages. The fact that we're still
discussing this now, and haven't settled on terminology acceptable to
all sides, illustrates the problem.
The Scheme report doesn't actually say anything about how latent types
relate to static types, in the way that I've recently characterized the
relationship here. However, I thought this was a good place to explain
how I got to where I am on this subject.
There's been a lot of work done on soft type inference in Scheme, and
other kinds of type analysis. The Scheme report talks about latent
types as meaning "types are associated with values". While this might
cause some teeth-grinding amongst type theorists, it's meaningful enough
when you look at simple cases: cases where the type of a term is an
exact match for the type tags of the values that flow through that term.
When you get to more complex cases, though, most type inferencers for
Scheme assign traditional static-style types to terms. If you think
about this in conjunction with the term "latent types", it's an obvious
connection to make that what the inferencer is doing is recovering types
that are latent in the source.
Once that connection is made, it's obvious that the tags associated with
values are not the whole story: that the conformance of one or more
values to a "latent type" may be checked by a series of tag checks, in
different parts of a program (i.e. before, during and after the
expression in question is evaluated). I gave a more detailed
description of how latent types relate to tags in an earlier reply to
Marshall (Spight, not Joe).
Anton
------------------------------
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 9348
***************************************
