[27967] in Perl-Users-Digest
Perl-Users Digest, Issue: 9331 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 21 09:05:54 2006
Date: Wed, 21 Jun 2006 06:05:04 -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 Wed, 21 Jun 2006 Volume: 10 Number: 9331
Today's topics:
Re: Find repeating substring <Peter@PSDT.com>
Re: Find repeating substring <Peter@PSDT.com>
Re: How to pronounce $ <tadmc@augustmail.com>
Reading the first .jpg file from a .rar archive? <ksheka@gmail.com>
Re: use of uninitialized value (beginner) <rvtol+news@isolution.nl>
Re: What is Expressiveness in a Computer Language <jo@durchholz.org>
Re: What is Expressiveness in a Computer Language <jo@durchholz.org>
Re: What is Expressiveness in a Computer Language <jo@durchholz.org>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Jun 2006 10:43:50 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: Find repeating substring
Message-Id: <pan.2006.06.21.10.44.41.555292@PSDT.com>
On Tue, 20 Jun 2006 06:29:48 -0700, Mike wrote:
> I need a regular expression to find repeating substrings (in particular
> the substring that starts in position 1 of the string and is repeated
> elsewhere in the string).
http://search.cpan.org/~gray/Tree-Suffix-0.14/lib/Tree/Suffix.pm
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
------------------------------
Date: Wed, 21 Jun 2006 10:47:36 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: Find repeating substring
Message-Id: <pan.2006.06.21.10.48.26.932722@PSDT.com>
Sorry, hit send too early.
On Tue, 20 Jun 2006 06:29:48 -0700, Mike wrote:
> I need a regular expression to find repeating substrings (in particular
> the substring that starts in position 1 of the string and is repeated
> elsewhere in the string). For example, in the case below, the substring
> of interest would be "HEART (CONDUCTION DEFECT)".
http://search.cpan.org/~gray/Tree-Suffix-0.14/lib/Tree/Suffix.pm
may not be a regular expression, but it is a Perl binding to a library
that you may be able to link to from another language (as you indicated
you are using). The link above has a link to that library.
On large amounts of data the regular expression solution can have
unacceptable performance. This is much faster.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
------------------------------
Date: Wed, 21 Jun 2006 07:52:14 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How to pronounce $
Message-Id: <slrne9ig7u.tbu.tadmc@magna.augustmail.com>
Hobo Salesman <hobosalesman@gmail.com> wrote:
> I realize this may be a stupid question but if theres one thing I don't
> fear it's making an ass of myself.
I can testify from extensive first-hand experience that embarrassing
yourself in front of hundreds of people is a very good way to
"internalize" lessons.
> How do you pronounce $, in the context of it defining a variable?
> "Dollar sign foo" is clumsy, so is the general pronounciation "scalar
> foo", "array foo", etc?
The general pronounciations are "$calar foo" and "@rray foo". :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 21 Jun 2006 04:59:35 -0700
From: "K P S" <ksheka@gmail.com>
Subject: Reading the first .jpg file from a .rar archive?
Message-Id: <1150891175.753695.208020@i40g2000cwc.googlegroups.com>
Can someone please point me to a small script to read the first .jpg
file from a .rar archive? I would like to create thumbnails of an
archive based on the first image file in the archive.
Also, are there perl routines for image manipulation? ie: scaleing an
image and converting from .jpg to .png?
I'm obviously someone totally new to perl, so any help would be
appreciated
Thanks!
------------------------------
Date: Wed, 21 Jun 2006 12:11:20 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: use of uninitialized value (beginner)
Message-Id: <e7bd6f.14o.1@news.isolution.nl>
Marek Stepanek schreef:
This is not about the uninitialized value.
> [\d,.\t\s]+
1. you just removed all ","
2. "\t" is in "\s"
So [\d.\s]+ would do the same.
So after a chomp, [\d.\t]+ would do.
> if ($line =~ /^$/)
> { ... }
> elsif ($line=~ /[\d.\t]+/)
Because you push only checked lines, the test in the elsif isn't needed.
A good habit is to always end with an else{}, like
else { die 'Should never reach this.' }.
If you need to make the checks on numbers stronger, Regexp::Common is
your friend.
http://search.cpan.org/search?module=Regexp::Common
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 21 Jun 2006 13:07:18 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7b98n$ji0$1@online.de>
Andreas Rossberg schrieb:
> Rob Thorpe wrote:
>> Hmm. You're right, ML is no-where in my definition since it has no
>> variables.
>
> Um, it has. Mind you, it has no /mutable/ variables, but that was not
> even what I was talking about.
Indeed. A (possibly nonexhaustive) list of program entities that (can)
have type would comprise of mutable variables, immutable variables (i.e.
constants and parameter names), and functions resp. their results.
Regards,
Jo
------------------------------
Date: Wed, 21 Jun 2006 13:10:55 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7b9fh$k1t$1@online.de>
Matthias Blume schrieb:
> Joachim Durchholz <jo@durchholz.org> writes:
>
>> Matthias Blume schrieb:
>>> Perhaps better: A language is statically typed if its definition
>>> includes (or ever better: is based on) a static type system, i.e., a
>>> static semantics with typing judgments derivable by typing rules.
>>> Usually typing judgmets associate program phrases ("expressions") with
>>> types given a typing environment.
>> This is defining a single term ("statically typed") using three
>> undefined terms ("typing judgements", "typing rules", "typing
>> environment").
>
> This was not meant to be a rigorous definition.
Rigorous or not, introducing additional undefined terms doesn't help
with explaining a term.
> Also, I'm not going to repeat the textbook definitions for those
> three standard terms here.
These terms certainly aren't standard for Perl, Python, Java, or Lisp,
and they aren't even standard for topics covered on comp.lang.functional
(which includes dynamically-typed languages after all).
Regards,
Jo
------------------------------
Date: Wed, 21 Jun 2006 13:24:39 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7ba98$lbo$1@online.de>
Pascal Costanza schrieb:
> (It's really important to understand that the idea is to use this for
> deployed programs - albeit hopefully in a more structured fashion - and
> not only for debugging. The example I have given is an extreme one that
> you would probably not use as such in a "real-world" setting, but it
> shows that there is a boundary beyond which static type systems cannot
> be used in a meaningful way anymore, at least as far as I can tell.)
As soon as the running program can be updated, the distinction between
"static" (compile time) and "dynamic" (run time) blurs.
You can still erect a definition for such a case, but it needs to refer
to the update process, and hence becomes language-specific. In other
words, language-independent definitions of dynamic and static typing
won't give any meaningful results for such languages.
I'd say it makes more sense to talk about what advantages of static vs.
dynamic typing can be applied in such a situation.
E.g. one interesting topic would be the change in trade-offs: making
sure that a type error cannot occur becomes much more difficult
(particularly if the set of available types can change during an
update), so static typing starts to lose some of its appeal; OTOH a good
type system can give you a lot of guarantees even in such a situation,
even if it might have to revert to the occasional run-time type check,
so static checking still has its merits.
Regards,
Jo
------------------------------
Date: Wed, 21 Jun 2006 10:31:31 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <44992e6c$0$664$bed64819@news.gradwell.net>
Darren New wrote:
[me:]
> > Personally, I would be quite happy to go there -- I dislike the idea
> > that a value has a specific inherent type.
>
> Interestingly, Ada defines a type as a collection of values. It works
> quite well, when one consistantly applies the definition.
I have never been very happy with relating type to sets of values (objects,
whatever). I'm not saying that it's formally wrong (but see below), but it
doesn't fit with my intuitions very well -- most noticeably in that the sets
are generally unbounded so you have to ask where the (intentional) definitions
come from.
Two other notions of what "type" means might be interesting, both come from
attempts to create type-inference mechanisms for Smalltalk or related
languages. Clearly one can't use the set-of-values approach for these purposes
;-) One approach takes "type" to mean "set of classes" the other takes a
finer-grained approach and takes it to mean "set of selectors" (where
"selector" is Smalltalk for "name of a method" -- or, more accurately, name of
a message).
But I would rather leave the question of what a type "is" open, and consider
that to be merely part of the type system. For instance the hypothetical
nullability analysis type system I mentioned might have only three types
NULLABLE, ALWAYSNULL, and NEVERNULL.
It's worth noting, too, that (in some sense) the type of an object can change
over time[*]. That can be handled readily (if not perfectly) in the informal
internal type system(s) which programmers run in their heads (pace the very
sensible post by Anton van Straaten today in this thread -- several branches
away), but cannot be handled by a type system based on sets-of-values (and is
also a counter-example to the idea that "the" dynamic type of an object/value
can be identified with its tag).
([*] if the set of operations in which it can legitimately partake changes.
That can happen explicitly in Smalltalk (using DNU proxies for instance if the
proxied object changes, or even using #becomeA:), but can happen anyway in less
"free" languages -- the State Pattern for instance, or even (arguably) in the
difference between an empty list and a non-empty list).
-- chris
------------------------------
Date: Wed, 21 Jun 2006 10:32:40 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <44992e6c$1$664$bed64819@news.gradwell.net>
Anton van Straaten wrote:
> 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.
I like this way of looking at it.
-- chris
------------------------------
Date: Wed, 21 Jun 2006 10:39:15 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <44992e6c$2$664$bed64819@news.gradwell.net>
David Hopwood wrote:
> When people talk
> about "types" being associated with values in a "latently typed" or
> "dynamically typed" language, they really mean *tag*, not type.
I don't think that's true. Maybe /some/ people do confuse the two, but I am
certainly a counter-example ;-)
The tag (if any) is part of the runtime machinery (or, if not, then I don't
understand what you mean by the word), and while that is certainly a reasonably
approximation to the type of the object/value, it is only an approximation,
and -- what's more -- is only an approximation to the type as yielded by one
specific (albeit abstract, maybe even hypothetical) type system.
If I send #someMessage to a proxy object which has not had its referent set
(and assuming the default value, presumably some variant of nil, does not
understand #someMessage), then that's just as much a type error as sending
#someMessage to a variable holding a nil value. If I then assign the referent
of the proxy to some object which does understand #someMessage, then it is not
a type error to send #someMessage to the proxy. So the type has changed, but
nothing in the tag system of the language implementation has changed.
-- chris
------------------------------
Date: Wed, 21 Jun 2006 10:54:00 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <44992e6c$3$664$bed64819@news.gradwell.net>
Chris Smith wrote:
> > It would be interesting to see what a language designed specifically to
> > support user-defined, pluggable, and perhaps composable, type systems
> > would look like. [...]
>
> You mean in terms of a practical programming language? If not, then
> lambda calculus is used in precisely this way for the static sense of
> types.
Good point. I was actually thinking about what a practical language might look
like, but -- hell -- why not start with theory for once ? ;-)
> I think Marshall got this one right. The two are accomplishing
> different things. In one case (the dynamic case) I am safeguarding
> against negative consequences of the program behaving in certain non-
> sensical ways. In the other (the static case) I am proving theorems
> about the impossibility of this non-sensical behavior ever happening.
And so conflating the two notions of type (-checking) as a kind of category
error ? If so then I see what you mean, and it's a useful distinction, but am
unconvinced that it's /so/ helpful a perspective that I would want to exclude
other perspectives which /do/ see the two as more-or-less trivial variants on
the same underlying idea.
> I acknowledge those questions. I believe they are valid. I don't know
> the answers. As an intuitive judgement call, I tend to think that
> knowing the correctness of these things is of considerable benefit to
> software development, because it means that I don't have as much to
> think about at any one point in time. I can validly make more
> assumptions about my code and KNOW that they are correct. I don't have
> to trace as many things back to their original source in a different
> module of code, or hunt down as much documentation. I also, as a
> practical matter, get development tools that are more powerful.
Agreed that these are all positive benefits of static declarative (more or
less) type systems.
But then (slightly tongue-in-cheek) shouldn't you be agitating for Java's type
system to be stripped out (we hardly /need/ it since the JVM does latent typing
anyway), leaving the field free for more powerful or more specialised static
analysis ?
> (Whether it's possible to create the same for a dynamically typed
> language is a potentially interesting discussion; but as a practical
> matter, no matter what's possible, I still have better development tools
> for Java than for JavaScript when I do my job.)
Acknowledged. Contrary-wise, I have better development tools in Smalltalk than
I ever expect to have in Java -- in part (only in part) because of the late
binding in Smalltalk and it's lack of insistence on declared types from an
arbitrarily chosen type system.
> On
> the other hand, I do like proving theorems, which means I am interested
> in type theory; if that type theory relates to programming, then that's
> great! That's probably not the thing to say to ensure that my thoughts
> are relevant to the software development "industry", but it's
> nevertheless the truth.
Saying it will probably win you more friends in comp.lang.functional than it
looses in comp.lang.java.programmer ;-)
-- chris
------------------------------
Date: 21 Jun 2006 05:17:36 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150892256.591282.43880@u72g2000cwu.googlegroups.com>
> 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.
I would suggest that at least assembly should be referred to as
"untyped".
------------------------------
Date: Wed, 21 Jun 2006 14:51:05 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7bfbq$8v164$3@hades.rz.uni-saarland.de>
Chris Uppal wrote:
>
> I have never been very happy with relating type to sets of values (objects,
> whatever).
Indeed, this view is much too narrow. In particular, it cannot explain
abstract types, which is *the* central aspect of decent type systems.
There were papers observing this as early as 1970. A type system should
rather be seen as a logic, stating invariants about a program. This can
include operations supported by values of certain types, as well as more
advanced properties, e.g. whether something can cause a side-effect, can
diverge, can have a deadlock, etc.
(There are also theoretic problems with the types-as-sets view, because
sufficiently rich type systems can no longer be given direct models in
standard set theory. For example, first-class polymorphism would run
afoul the axiom of foundation.)
> It's worth noting, too, that (in some sense) the type of an object can change
> over time[*].
No. Since a type expresses invariants, this is precisely what may *not*
happen. If certain properties of an object may change then the type of
the object has to reflect that possibility. Otherwise you cannot
legitimately call it a type.
Taking your example of an uninitialised reference, its type is neither
"reference to nil" nor "reference to object that understands message X",
it is in fact the union of both (at least). And indeed, languages with
slightly more advanced type systems make things like this very explicit
(in ML for example you have the option type for that purpose).
- Andreas
------------------------------
Date: Wed, 21 Jun 2006 15:01:33 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fsu9dF1k21c9U1@individual.net>
Joachim Durchholz wrote:
> Pascal Costanza schrieb:
>> (It's really important to understand that the idea is to use this for
>> deployed programs - albeit hopefully in a more structured fashion -
>> and not only for debugging. The example I have given is an extreme one
>> that you would probably not use as such in a "real-world" setting, but
>> it shows that there is a boundary beyond which static type systems
>> cannot be used in a meaningful way anymore, at least as far as I can
>> tell.)
>
> As soon as the running program can be updated, the distinction between
> "static" (compile time) and "dynamic" (run time) blurs.
> You can still erect a definition for such a case, but it needs to refer
> to the update process, and hence becomes language-specific. In other
> words, language-independent definitions of dynamic and static typing
> won't give any meaningful results for such languages.
>
> I'd say it makes more sense to talk about what advantages of static vs.
> dynamic typing can be applied in such a situation.
> E.g. one interesting topic would be the change in trade-offs: making
> sure that a type error cannot occur becomes much more difficult
> (particularly if the set of available types can change during an
> update), so static typing starts to lose some of its appeal; OTOH a good
> type system can give you a lot of guarantees even in such a situation,
> even if it might have to revert to the occasional run-time type check,
> so static checking still has its merits.
I am not opposed to this view. The two examples I have given for things
that are impossible in static vs. dynamic type systems were
intentionally extreme to make the point that you have to make a choice,
that you cannot just blindly throw (instances of) both approaches
together. Static type systems potentially change the semantics of a
language in ways that cannot be captured by dynamically typed languages
anymore, and vice versa.
There is, of course, room for research on performing static type checks
in a running system, for example immediately after or before a software
update is applied, or maybe even on separate type checking on software
increments such that guarantees for their composition can be derived.
However, I am not aware of a lot of work in that area, maybe because the
static typing community is too focused on compile-time issues.
Personally, I also don't think that's the most interesting issue in that
area, but that's of course only a subjective opinion.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
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 9331
***************************************
