[28023] in Perl-Users-Digest
Perl-Users Digest, Issue: 9387 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 26 21:06:49 2006
Date: Mon, 26 Jun 2006 18:05:05 -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, 26 Jun 2006 Volume: 10 Number: 9387
Today's topics:
Re: Please help Perl Newbie understand this statement jm-1@remotekontrol.com
Re: Please help Perl Newbie understand this statement <tadmc@augustmail.com>
Re: Please help Perl Newbie understand this statement <tadmc@augustmail.com>
Re: reference to object method <ced@blv-sam-01.ca.boeing.com>
Re: Regular Expression Generator <noreply@invalid.net>
Re: Regular Expression Generator <rvtol+news@isolution.nl>
Re: Termination and type systems <david.nospam.hopwood@blueyonder.co.uk>
Re: What is a type error? <david.nospam.hopwood@blueyonder.co.uk>
Re: What is a type error? <pc@p-cos.net>
Re: What is a type error? <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <cfc@shell01.TheWorld.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <sleepingsquirrel@yahoo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Jun 2006 15:11:28 -0700
From: jm-1@remotekontrol.com
Subject: Re: Please help Perl Newbie understand this statement
Message-Id: <1151359888.833482.258780@y41g2000cwy.googlegroups.com>
Hi Jurgen
If the current line starts with a word character
> "\w Match a "word" character (alphanumeric plus "_")"
what does the m/^ mean in " if (m/^\w/)"
I must sound very inexperienced! I have not come accroos this sytax in
the tutorials yet.
Thank you so much for your time
Regards
Andy
J=FCrgen Exner wrote:
> jm-1@remotekontrol.com wrote:
> > I have not programmed before and I am doing my best to get to grips
> > with Perl in order to decode and modify a backup script. Could anyone
> > please explain the following line in plain english to me? I understand
> > that what we are saying is "While the file handle <CONFIG> is
> > available,
>
> Nope. That line means "While the file that is referenced by the file hand=
le
> CONFIG has not reached EndOfFile (i.e. while there are still lines
> available)" loop through each line in sequence."
>
> > chomp the newline character of off each line as we read it"
> > and then I am lost.
>
> > while (<CONFIG>)
> > {
> > chomp;
> > if (m/^\w/)
>
> If the current line starts with a word character
> "\w Match a "word" character (alphanumeric plus "_")"
> then
>
> > {
> > ($key, $data) =3D split /=3D/, $_;
>
> Split the current line at any equal sign "=3D", store the first part in $=
key,
> store the second part in $data, ignore any other parts.
>
> > $array{$key} =3D $data;
>
> And store $data in the hash named %array at the data point $key. BTW: usi=
ng
> %array for a hash is somewhat misleading.
>=20
> jue
------------------------------
Date: Mon, 26 Jun 2006 17:49:41 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Please help Perl Newbie understand this statement
Message-Id: <slrnea0p45.pij.tadmc@magna.augustmail.com>
jm-1@remotekontrol.com <jm-1@remotekontrol.com> wrote:
> Thank You very much for your help.
You are welcome.
I am going to ask something in return.
Please compose followups the proper way, quoting only what you are
going to comment on, trimming stuff that you are not going to comment
on, and interleaving your comments after the quoted text that the
comment applies to.
Have you seen the Posting Guidelines that are posted here frequently?
> I have been reading the tutorials @
> http://learn.perl.org/library/beginning_perl/.
Oh, allright then. You've managed to find one of the good ones. :-)
> I have always avoided programming because I find
> it frustrating
If the frustration is something that you would prefer to not deal
with, then you can always hire an actual programmer. (like me!)
heh.
[ snip TOFU ]
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 26 Jun 2006 17:54:37 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Please help Perl Newbie understand this statement
Message-Id: <slrnea0pdd.pij.tadmc@magna.augustmail.com>
jm-1@remotekontrol.com <jm-1@remotekontrol.com> wrote:
> If the current line starts with a word character
>> "\w Match a "word" character (alphanumeric plus "_")"
>
> what does the m/^ mean in " if (m/^\w/)"
m// is the syntax for the pattern match operator (regular expressions).
You can use a delimiter other than slash if you like, eg: m## m!!
If you choose to use slash as your delimiter, then you are
allowed to leave off the "m", eg: //
A caret (^) in a regex matches the beginning of the string.
So then, m/^\w/ will match (and return true) if the 1st
character in $_ is one of the 63 "word" characters.
[ snip more TOFU ]
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 26 Jun 2006 23:11:01 GMT
From: Charles DeRykus <ced@blv-sam-01.ca.boeing.com>
Subject: Re: reference to object method
Message-Id: <J1HpqD.2vp@news.boeing.com>
Hobo Salesman wrote:
> Can I store a reference to an object method in a scalar and use that to
> call the method? Something like (and I'm sure this is wrong):
>
> $methodRef = \$object->method();
No, that invokes the method and gives you a reference to the return
value (or last return value if the method returns a list)*.
* See Recipe 11.8 "Creating References to Methods" in the `Perl
Cookbook`. The recipe explains why UNIVERSAL's `can` method falls
short as well.
And, as mentioned though, the working solutions don't preserve inheritance.
> &{$methodRef}($argument);
--
Charles DeRykus
------------------------------
Date: Mon, 26 Jun 2006 23:55:42 GMT
From: Ala Qumsieh <noreply@invalid.net>
Subject: Re: Regular Expression Generator
Message-Id: <2u_ng.54036$fb2.4149@newssvr27.news.prodigy.net>
Dr.Ruud wrote:
> Ted Zlatanov schreef:
>
>> my $regex = '^(' . join('|', @strings) . ')$';
>>
>> and that's a regex that will match any given non-empty strings.
>
> '^(?:' . join( '|', map quotemeta, grep /./, @strings ) . ')$'
This solution has a caveat. Regexps have a maximum length (65539 bytes I
believe). If you have enough strings in @strings (or if they are long
enough), then the compiled regexp can exceed this length, and error out. I
encountered this once, and the solution I resorted to was to construct an
anonymous sub on the fly:
my $string = <<EOS;
sub {
local \$_ = shift;
return 1 if /\Q$string[0]\E/;
return 1 if /\Q$string[1]\E/;
....
}
EOS
my $matches = eval $string;
Then use this anon sub to match:
if ($matches->($myString)) { ... }
--Ala
------------------------------
Date: Tue, 27 Jun 2006 02:49:51 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Regular Expression Generator
Message-Id: <e7q6f2.b4.1@news.isolution.nl>
Ala Qumsieh schreef:
> Dr.Ruud:
>> Ted Zlatanov:
>>> my $regex = '^(' . join('|', @strings) . ')$';
>>>
>>> and that's a regex that will match any given non-empty strings.
>>
>> '^(?:' . join( '|', map quotemeta, grep /./, @strings ) . ')$'
>
> This solution has a caveat. Regexps have a maximum length (65539
> bytes I believe). If you have enough strings in @strings (or if they
> are long enough), then the compiled regexp can exceed this length,
> and error out. I encountered this once, and the solution I resorted
> to was to construct an anonymous sub on the fly:
If so, it would have the same problem, because any of the strings can be
too long.
perl -Mwarnings -le '
$n = 1_000_000 ;
$_ = ".." x $n ;
$r = qr/^\Q$_\E$/ ;
print length($r), ":", /$r/ ;
'
prints 4000011:1
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Mon, 26 Jun 2006 22:23:25 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: Termination and type systems
Message-Id: <x7Zng.482167$xt.178802@fe3.news.blueyonder.co.uk>
Dirk Thierbach wrote:
> David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
>>Marshall wrote:
>>>David Hopwood wrote:
>
>>>>A type system that required an annotation on all subprograms that
>>>>do not provably terminate, OTOH, would not impact expressiveness
>>>>at all, and would be very useful.
>
>>>Interesting. I have always imagined doing this by allowing an
>>>annotation on all subprograms that *do* provably terminate.
>
> Maybe the paper "Linear types and non-size-increasing polynomial time
> computation" by Martin Hofmann is interesting in this respect.
<http://citeseer.ist.psu.edu/hofmann98linear.html>
> From the abstract:
>
> We propose a linear type system with recursion operators for inductive
> datatypes which ensures that all definable functions are polynomial
> time computable. The system improves upon previous such systems in
> that recursive definitions can be arbitrarily nested; in particular,
> no predicativity or modality restrictions are made.
>
> It does not only ensure termination, but termination in polynomial time,
> so you can use those types to carry information about this as well.
That's interesting, but linear typing imposes some quite severe
restrictions on programming style. From the example of 'h' on page 2,
it's clear that the reason for the linearity restriction is just to
ensure polynomial-time termination, and is not needed if we only want
to prove termination.
>>If the annotation marks not-provably-terminating subprograms, then it
>>calls attention to those subprograms. This is what we want, since it is
>>less safe/correct to use a nonterminating subprogram than a terminating
>>one (in some contexts).
>
> That would be certainly nice, but it may be almost impossible to do in
> practice. It's already hard enough to guarantee termination with the
> extra information present in the type annotation. If this information
> is not present, then the language has to be probably restricted so
> severely to ensure termination that it is more or less useless.
I think you're overestimating the difficulty of the problem. The fact
that *in general* it can be arbitrarily hard to prove termination, can
obscure the fact that for large parts of a typical program, proving
termination is usually trivial.
I just did a manual termination analysis for a 11,000-line multithreaded
C program; it's part of a control system for some printer hardware. This
program has:
- 212 functions that trivially terminate. By this I mean that the function
only contains loops that have easily recognized integer loop variants,
and only calls other functions that are known to trivially terminate,
without use of recursion. A compiler could easily prove these functions
terminating without need for any annotations.
- 8 functions that implement non-terminating event loops.
- 23 functions that intentionally block. All of these should terminate
(because of timeouts, or because another thread should do something that
releases the block), but this cannot be easily proven with the kind of
analysis we're considering here.
- 3 functions that read from a stdio stream into a fixed-length buffer. This
is guaranteed to terminate when reading a normal file, but not when reading
from a pipe. In fact the code never reads from a pipe, but that is not
locally provable.
- 2 functions that iterate over a linked list of network adaptors returned
by the Win32 GetAdaptorsInfo API. (This structure could be recognized as
finite if we were calling a standard library abstraction over the OS API,
but we are relying on Windows not to return a cyclic list.)
- 1 function that iterates over files in a directory. (Ditto.)
- 2 functions that iterate over a queue, implemented as a linked list. The queue
is finite, but this is not locally provable. Possibly an artifact of the lack
of abstraction from using C, where the loop is not easily recognizable as an
iteration over a finite data structure.
- 1 function with a loop that terminates for a non-trivial reason that involves
some integer arithmetic, and is probably not expressible in a type system.
The code aready had a comment informally justifying why the loop terminates,
and noting a constraint needed to avoid an arithmetic overflow.
(Bignum arithmetic would avoid the need for that constraint.)
- 2 functions implementing a simple parsing loop, which terminates because the
position of the current token is guaranteed to advance -- but this probably
would not be provable given how the loop is currently written. A straightforward
change (to make the 'next token' function return the number of characters to
advance, asserted to be > 0, instead of a pointer to the next token) would make
the code slightly clearer, and trivially terminating.
So for this program, out of 254 functions:
- 83.5% are trivially terminating already.
- 12.2% would need annotations saying that they are intended to block or not
to terminate. This is largely an artifact -- we could remove the need for
*all* of these annotations by adopting an event-loop concurrency model, and
only attempting to prove termination of functions within a "turn" (one
iteration of each top-level loop).
- 2.4% would need annotations saying that termination is too hard to prove --
but only because they interact with the operating system.
This is obviously not a type system problem; fixing it requires careful
design of the language's standard library.
- 0.8% would need annotations only in C; in a language with standard libraries
that provide data structures that are guaranteed to be finite, they probably
would not.
- 1.2% would need changes to the code, or are genuinely too difficult to prove
to be terminating using a type system.
This is obviously not a large program (although I wouldn't want to do a manual
analysis like this for a much larger one), and it may be atypical in that it has
almost no use of recursion (or maybe that *is* typical for C programs). It would
be interesting to do the same kind of analysis for a functional program, or one
that does a more "algorithmically intensive" task.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Mon, 26 Jun 2006 22:40:10 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is a type error?
Message-Id: <enZng.220091$8W1.160512@fe1.news.blueyonder.co.uk>
Pascal Costanza wrote:
> David Hopwood wrote:
>> Pascal Costanza wrote:
>>> Chris Smith wrote:
>>>
>>>> While this effort to salvage the term "type error" in dynamic
>>>> languages is interesting, I fear it will fail. Either we'll all have
>>>> to admit that "type" in the dynamic sense is a psychological concept
>>>> with no precise technical definition (as was at least hinted by
>>>> Anton's post earlier, whether intentionally or not) or someone is
>>>> going to have to propose a technical meaning that makes sense,
>>>> independently of what is meant by "type" in a static system.
>>>
>>> What about this: You get a type error when the program attempts to
>>> invoke an operation on values that are not appropriate for this
>>> operation.
>>>
>>> Examples: adding numbers to strings; determining the string-length of a
>>> number; applying a function on the wrong number of parameters; applying
>>> a non-function; accessing an array with out-of-bound indexes; etc.
>>
>> This makes essentially all run-time errors (including assertion failures,
>> etc.) "type errors". It is neither consistent with, nor any improvement
>> on, the existing vaguely defined usage.
>
> Nope. This is again a matter of getting the levels right.
>
> Consider division by zero: appropriate arguments for division are
> numbers, including the zero. The dynamic type check will typically not
> check whether the second argument is zero, but will count on the fact
> that the processor will raise an exception one level deeper.
That is an implementation detail. I don't see its relevance to the above
argument at all.
> This is maybe better understandable in user-level code. Consider the
> following class definition:
>
> class Person {
> String name;
> int age;
>
> void buyPorn() {
> if (< this.age 18) throw new AgeRestrictionException();
> ...
> }
> }
>
> The message p.buyPorn() is a perfectly valid message send and will pass
> both static and dynamic type tests (given p is of type Person in the
> static case). However, you will still get a runtime error.
Your definition above was "You get a type error when the program attempts
to invoke an operation on values that are not appropriate for this operation."
this.age, when less than 18, is a value that is inappropriate for the buyPorn()
operation, and so this satisfies your definition of a type error. My point was
that it's difficult to see any kind of program error that would *not* satisfy
this definition.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Tue, 27 Jun 2006 01:28:53 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is a type error?
Message-Id: <4gb8tiF1e75njU1@individual.net>
Chris Smith wrote:
> Pascal Costanza <pc@p-cos.net> wrote:
>> Chris Smith wrote:
>>> Of course zero is not appropriate as a second argument to the division
>>> operator! I can't possibly see how you could claim that it is. The
>>> only reasonable statement worth making is that there doesn't exist a
>>> type system in widespread use that is capable of checking this.
>> ...and this is typically not even checked at the stage where type tags
>> are checked in dynamically-typed languages. Hence, it is not a type
>> error. (A type error is always what you define to be a type error within
>> a given type system, right?)
>
> Sure, it's not a type error for that language.
>
>> Note, this example was in response to David's reply that my definition
>> turns every runtime error into a type error. That's not the case, and
>> that's all I want to say.
>
> But your definition does do that. Your definition of a type error was
> when a program attempts to invoke an operation on values that are not
> appropriate for this operation.
In my definition, I didn't say who or what decides what values are
appropriate for operations.
> Clearly, in this example, the program
> is invoking an operation (division) on values that are not appropriate
> (zero for the second argument). Hence, if your definition really is a
> definition, then this must qualify.
Here, you are asking more from dynamic type systems than any existing
type system provides. The definition of what is considered to be a type
error and what not is always part of the specification of a type system.
>>> However, it sounds as
>>> if you're claiming that it wouldn't be possible for the type system to
>>> do this?
>> No. I only need an example where a certain error is not a type error in
>> _some_ language. I don't need to make a universal claim here.
>
> Definitions are understood to be statements of the form "if and only
> if". They assert that /everything/ that fits the definition is
> describable by the word, and /everything/ that doesn't is not
> describable by the word. If that's not what you meant, then we are
> still in search of a definition.
>
> If you want to make a statement instead of the sort you've implied
> above... namely that a type error is *any* error that's raised by a type
> system, then that's fine. It certainly brings us closer to static
> types. Now, though, the task is to define a type system without making
> a circular reference to types. You've already rejected the statement
> that all runtime errors are type errors, because you specifically reject
> the division by zero case as a type error for most languages. What is
> that distinction?
I don't need such a distinction. I can just define what is covered by a
type system and what is not. All type systems work that way.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Mon, 26 Jun 2006 17:47:40 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f0a200a59a26bd9989718@news.altopia.net>
Pascal Costanza <pc@p-cos.net> wrote:
> > Clearly, in this example, the program
> > is invoking an operation (division) on values that are not appropriate
> > (zero for the second argument). Hence, if your definition really is a
> > definition, then this must qualify.
>
> Here, you are asking more from dynamic type systems than any existing
> type system provides. The definition of what is considered to be a type
> error and what not is always part of the specification of a type system.
No, I'm not. Were we to follow this path of definition, it would not
require that dynamic type systems catch ALL type errors; only that they
catch some. Not that it matters, though. I am analyzing the logical
consequences of your own definition. If those logical consequences were
impossible to fulfill, that would be an even more convincing reason to
find a new definition. Concepts of fairness don't enter into the
equation.
> > If you want to make a statement instead of the sort you've implied
> > above... namely that a type error is *any* error that's raised by a type
> > system, then that's fine. It certainly brings us closer to static
> > types. Now, though, the task is to define a type system without making
> > a circular reference to types. You've already rejected the statement
> > that all runtime errors are type errors, because you specifically reject
> > the division by zero case as a type error for most languages. What is
> > that distinction?
>
> I don't need such a distinction. I can just define what is covered by a
> type system and what is not. All type systems work that way.
You've got to define something... or, I suppose, just go on using words
without definitions. You claimed to give a definition, though.
I have been led by others to believe that the right way to go in the
dynamic type sense is to first define type errors, and then just call
anything that finds type errors a type system. That would work, but it
would require a type error. You seem to want to push that work off of
the word "type error" and back onto "type system", but that requires
that you define what a type system is. It doesn't work for you to say
BOTH that a type system is anything that catches type errors, AND that a
type error is anything that's caught by a type system. That's not a
definition; it's just circular reasoning. If I can plug in: type error
= fly, type system = frog, and get a valid instance of your definitions,
then you aren't giving much of a definition. (Unless you think that
frogs are perfectly good examples of type systems.)
Incidentally, in the case of static type systems, we define the system
(for example, using the definition given from Pierce many times this
thread), and then infer the definition of types and type errors from
there. Because a solid definition has been given first for a type
system without invoking the concepts of types or type errors, this
avoids being circular.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 26 Jun 2006 18:13:16 -0400
From: Chris F Clark <cfc@shell01.TheWorld.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <sddk673lg5f.fsf@shell01.TheWorld.com>
I wrote:
> These informal systems, which may not prove what they claim to prove
> are my concept of a "type system".
Chris Smith <cdsmith@twu.net> replied:
> Okay, that works. I'm not sure where it gets us, though....
Ok, we'll get there. First, we need to step back in time, to when there
was roughly algol, cobol, fortran, and lisp. Back then, at least as I
understood things, there were only a few types that generally people
understood integer, real, and (perhaps) pointer. Now, with algol or
fortran things were generally only of the first two types and
variables were statically declared to be one or the other. With lisp
any cell could hold any one of the 3, and some clever implementor
added "tag bits" to distinguish which the cell held. As I understood
it, the tag bits weren't originally for type correctness, so much as
they facilitated garbage collection. The garbage collector didn't
know what type of data you put in a cell and had to determine which
cells contained pointers, so that the mark-and-sweep algorithms could
sweep by following the pointers (and not following the integers that
looked like pointers). Still, these tag bits did preserve the
"dynamic" type, in the sense that we knew types from the other
languages. As I remember it, sophistication with type really didn't
occur as a phenomena for the general programmer until the introduction
of Pascal (and to a lesser extent PL/I). Moreover, as I recall it,
perhaps because I didn't learn the appropriate dialect was that lisp
dialects kept with the more general notion of type (lists and tuples)
and eschewed low-level bit-fiddling where we might want to talk about
a 4 bit integer representing 0 .. 15 or -8 .. 7.
The important thing is the dynamicism of lisp allowed one to write
polymorphic programs, before most of us knew the term. However, we
still had a notion of type: integers and floating point numbers were
still different and one could not portably use integer operations on
floating pointer values or vice versa. However, one could check the
tag and "do the right thing" and many lisp primitives did just that,
making them polymorphic.
The way most of us conceived (or were taught to conceive) of the
situation was that there still were types, they were just associated
with values and the type laws we all knew and loved still worked, they
just worked dynamically upon the types of the operand values that were
presented at the time.
Can this be made rigorous? Perhaps.
Instead of viewing the text of the program staticly, let us view it
dynamicly, that is by introducing a time (or execution) dimension.
This is easier if you take an imperative view of the dynamic program
and imagine things having an operational semantics, which is why we
stepped back in time in the first place, so that we are in a world
where imperative programming is the default model for most
programmers.
Thus, as we traverse a list, the first element might be an integer,
the second a floating point value, the third a sub-list, the fourth
and fifth, two more integers, and so on. If you look statically at
the head of the list, we have a very wide union of types going by.
However, perhaps there is a mapping going on that can be discerned.
For example, perhaps the list has 3 distinct types of elements
(integers, floating points, and sub-lists) and it circles through the
types in the order, first having one of each type, then two of each
type, then four of each type, then eight, and so on. The world is now
patterned.
However, I don't know how to write a static type annotation that
describes exactly that type. That may just be my lack of experience
in writing annotations. However, it's well within my grasp to imagine
the appropriate type structure, even though **I** can't describe it
formally. More importantly, I can easily write something which checks
the tags and sees whether the data corresponds to my model.
And, this brings us to the point, if the data that my program
encounters doesn't match the model I have formulated, then something
is of the wrong "type". Equally importantly, the dynamic tags, have
helped me discover that type error.
Now, the example may have seemed arbitrary to you, and it was in some
sense arbitrary. However, if one imagines a complete binary tree with
three kinds elements stored in memory as rows per depth, one can get
exactly the structure I described. And, if one were rewriting that
unusual representation to a more normal one, one might want exactly
the "type check" I proposed to validate that the input binary tree was
actually well formed.
Does this help explain dynamic typing as a form of typing?
-Chris
------------------------------
Date: Mon, 26 Jun 2006 22:53:25 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <FzZng.16310$Z67.15253@tornado.socal.rr.com>
Joachim Durchholz wrote:
> That's actually not a design choice
It's certainly a choice you can get wrong, as you say. ;-)
I mean, if "without runtime safety" is a choice, I expect picking the
wrong choice here can be. :-)
--
Darren New / San Diego, CA, USA (PST)
Native Americans used every part
of the buffalo, including the wings.
------------------------------
Date: Mon, 26 Jun 2006 17:33:29 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0a1caffd8f6cbf989717@news.altopia.net>
Chris F Clark <cfc@shell01.TheWorld.com> wrote:
> Ok, we'll get there. First, we need to step back in time, to when there
> was roughly algol, cobol, fortran, and lisp. Back then, at least as I
> understood things, there were only a few types that generally people
> understood integer, real, and (perhaps) pointer.
In order to continue my tradition of trying to be as precise as
possible, let me point out that of course there were more "candidate
types", as it were, and that people understood them just fine. They
just didn't have a type system in place to make them into real types, so
they didn't think to call them types.
> The important thing is the dynamicism of lisp allowed one to write
> polymorphic programs, before most of us knew the term.
Sure. In exchange for giving up the proofs of the type checker, you
could write all kinds of programs. To this day, we continue to write
programs in languages with dynamic checking features because we don't
have powerful enough type systems to express the corresponding type
system.
> Thus, as we traverse a list, the first element might be an integer,
> the second a floating point value, the third a sub-list, the fourth
> and fifth, two more integers, and so on. If you look statically at
> the head of the list, we have a very wide union of types going by.
> However, perhaps there is a mapping going on that can be discerned.
> For example, perhaps the list has 3 distinct types of elements
> (integers, floating points, and sub-lists) and it circles through the
> types in the order, first having one of each type, then two of each
> type, then four of each type, then eight, and so on. The world is now
> patterned.
>
> However, I don't know how to write a static type annotation that
> describes exactly that type.
I believe that, in fact, it would be trivial to imagine a type system
which is capable of expressing that type. Okay, not trivial, since it
appears to be necessary to conceive of an infinite family of integer
types with only one value each, along with range types, and
relationships between them; but it's probably not completely beyond the
ability of a very bright 12-year-old who has someone to describe the
problem thoroughly and help her with the notation.
The more interesting problem is whether this type system could be made:
(a) unobstrusive enough, probably via type inference or something along
those lines, that it would be usable in practice; and (b) general enough
that you could define a basic type operator that applies to a wide range
of problems rather than revising your type operator the first time you
need a complete 3-tree of similar form.
> That may just be my lack of experience
> in writing annotations.
You would, of course, need a suitable type system first. For example,
it appears to me that there is simply no possible way of expressing what
you've described in Java, even with the new generics features. Perhaps
it's possible in ML or Haskell (I don't know). My point is that if you
were allowed to design a type system to meet your needs, I bet you could
do it.
> And, this brings us to the point, if the data that my program
> encounters doesn't match the model I have formulated, then something
> is of the wrong "type". Equally importantly, the dynamic tags, have
> helped me discover that type error.
Sure. The important question, then, is whether there exists any program
bug that can't be formulated as a type error. And if so, what good does
it do us to talk about type errors when we already have the perfectly
good word "bug" to describe the same concept?
> Now, the example may have seemed arbitrary to you, and it was in some
> sense arbitrary.
Arbitrary is good. One of the pesky things that keeps getting in the
way here is the intuition attached to the word "type" that makes
everyone think "string or integer".
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 26 Jun 2006 17:34:03 -0700
From: "Greg Buchholz" <sleepingsquirrel@yahoo.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151368443.491445.294480@p79g2000cwp.googlegroups.com>
Chris F Clark wrote:
> Thus, as we traverse a list, the first element might be an integer,
> the second a floating point value, the third a sub-list, the fourth
> and fifth, two more integers, and so on. If you look statically at
> the head of the list, we have a very wide union of types going by.
> However, perhaps there is a mapping going on that can be discerned.
> For example, perhaps the list has 3 distinct types of elements
> (integers, floating points, and sub-lists) and it circles through the
> types in the order, first having one of each type, then two of each
> type, then four of each type, then eight, and so on.
Sounds like an interesting problem. Although not the exact type
specified above, here's something pretty similar that I could think of
implementing in Haskell. (I don't know what a "sub-list" is, for
example). Maybe some Haskell wizard could get rid of the tuples?
data Clark a b c = Nil | Cons a (Clark b c (a,a)) deriving Show
clark = (Cons 42 (Cons 3.14 (Cons "abc"
(Cons (1,2) (Cons (1.2,3.4) (Cons ("foo","bar")
(Cons ((9,8),(7,6)) (Cons ((0.1,0.2),(0.3,0.4)) Nil))))))))
main = print clark
------------------------------
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 9387
***************************************
