[27985] in Perl-Users-Digest
Perl-Users Digest, Issue: 9349 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 00:05:46 2006
Date: Thu, 22 Jun 2006 21: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 Thu, 22 Jun 2006 Volume: 10 Number: 9349
Today's topics:
Hash of Arrays <pradeep.bg@gmail.com>
Help with worthy project ? <hooper1@optonline.net>
Re: Help with worthy project ? <jurgenex@hotmail.com>
Matching strings without repeated spaces usenet@DavidFilmer.com
Re: Matching strings without repeated spaces <tadmc@augustmail.com>
Re: Matching strings without repeated spaces <attn.steven.kuo@gmail.com>
Re: Matching strings without repeated spaces <xicheng@gmail.com>
Online Graphing Calculator - Perl Backend robby.walker@gmail.com
Re: Running another program in daemon server <janicehwang1325@yahoo.com>
Re: Running another program in daemon server <janicehwang1325@yahoo.com>
Re: Running another program in daemon server <janicehwang1325@yahoo.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: Why doesn't chdir (@args) work? <register_allocation@lycos.com>
Re: Why doesn't chdir (@args) work? <sherm@Sherm-Pendleys-Computer.local>
Re: Why doesn't chdir (@args) work? <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Jun 2006 18:58:39 -0700
From: "Deepu" <pradeep.bg@gmail.com>
Subject: Hash of Arrays
Message-Id: <1151027918.896970.234080@r2g2000cwb.googlegroups.com>
Hi All,
I have a problem and i am not able to get what might be a better way of
solving this. Can somebody please give me some ideas on solving this.
I have a file which have transitions like:
STATE1
STATE3
STATEMAIN ####
STATESUSPEND
STATE1
STATE2
STATERESUME
RESET
STATE6
STATE8
STATEMAIN ####
STATE9
STATE10
This indicates a transition from STATE1 to STATE3, then STATE3 to
STATEMAIN and so on. There are also 10 files which will have different
combinations of these states.
Here i need to go through the file and check for STATEMAIN and when i
see STATEMAIN, then i need to put it in an array till i see RESET or
end of file. After that again i need to proceed further to check
whether there is any more STATEMAIN. If present again i need to put it
in a different array till RESET or end of file.
I need to store it in an hash:
%hash = (
FILE1 => ["STATEMAIN", "STATESUSPEND", "STATE1",
"STATE2", "STATERESUME", "RESET"],
FILE1 => ["STATEMAIN", "STATE9", "STATE10"],
FILE2 => - - - - -
);
and also if there is no STATEMAIN in any file there is no need of
putting in the hash.
Please help me on this.
Thanks
Deep
------------------------------
Date: 22 Jun 2006 20:32:13 -0700
From: "GHBoom" <hooper1@optonline.net>
Subject: Help with worthy project ?
Message-Id: <1151033533.058951.11440@r2g2000cwb.googlegroups.com>
Hello,
Im writing a program, for Filezilla brute force detection,
and man just found a bug I introduced way back....
I was wondering if anyone here would be interested in helping
me clean it up, and help me get it ready to use strict ?
In general, there is more then one way to do it in perl, I guess I
did it my way, at the very least, 90% is readable and easy to digest.
If your interested, What I would like to do first is,
Clean it up...
for example as the script evolved
I used at one point @here=sort(@there)
looking at it many many changes later, Im left ondering why I just
didnt
sort(@there) and be done with it !
Anyway, if you would like to contribute to an open source project
that may just take off, please let me know ;-)
GHBoom
------------------------------
Date: Fri, 23 Jun 2006 03:52:45 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Help with worthy project ?
Message-Id: <hAJmg.170$Wl.46@trnddc01>
GHBoom wrote:
> for example as the script evolved
> I used at one point @here=sort(@there)
> looking at it many many changes later, Im left ondering why I just
> didnt
> sort(@there) and be done with it !
Maybe because you wanted to _use_ the sorted result and not compute it and
then ignore it?
jue
------------------------------
Date: 22 Jun 2006 18:31:25 -0700
From: usenet@DavidFilmer.com
Subject: Matching strings without repeated spaces
Message-Id: <1151026285.547285.25600@p79g2000cwp.googlegroups.com>
I want to construct a regexp which will match a string containing only
\w and \s, but not repeated whitespaces. I can do it (crudely) with
two regexps, such as:
if (/[\w\s-]+$/ && ! /\s\s/) {
but I'd rather do it with a single regexp... but guessing at the syntax
has not proved effective.
I'd appreciate some insight...
Thanks!
--
David Filmer (http://DavidFilmer.com)
------------------------------
Date: Thu, 22 Jun 2006 21:13:17 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Matching strings without repeated spaces
Message-Id: <slrne9mjht.6h0.tadmc@magna.augustmail.com>
usenet@DavidFilmer.com <usenet@DavidFilmer.com> wrote:
> I want to construct a regexp which will match a string containing only
> \w and \s,
Then you should anchor _both_ ends of the pattern.
> but not repeated whitespaces. I can do it (crudely) with
> two regexps, such as:
>
> if (/[\w\s-]+$/ && ! /\s\s/) {
>
> but I'd rather do it with a single regexp...
> I'd appreciate some insight...
Use a negative lookahead assertion:
if ( /^(\w+|\s(?!\s))+$/ ) {
or, written for human consumption:
if ( /^ (
\w+
|
\s(?!\s)
)+
$/x
) {
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 22 Jun 2006 19:25:08 -0700
From: "attn.steven.kuo@gmail.com" <attn.steven.kuo@gmail.com>
Subject: Re: Matching strings without repeated spaces
Message-Id: <1151029508.577117.4680@u72g2000cwu.googlegroups.com>
usenet@DavidFilmer.com wrote:
> I want to construct a regexp which will match a string containing only
> \w and \s, but not repeated whitespaces. I can do it (crudely) with
> two regexps, such as:
>
> if (/[\w\s-]+$/ && ! /\s\s/) {
>
> but I'd rather do it with a single regexp... but guessing at the syntax
> has not proved effective.
>
> I'd appreciate some insight...
>
> Thanks!
I'd go with:
if (/^(\w*(?>\s*)(?<!\s{2}))*$/)
{
print $_;
}
# or
if (/^(?=[\w\s])(\w*(?>\s*)(?<!\s{2}))+$/)
{
print $_;
}
depending on whether or not you want the
empty string to match.
--
Hope this helps,
Steven
------------------------------
Date: 22 Jun 2006 19:45:42 -0700
From: "Xicheng Jia" <xicheng@gmail.com>
Subject: Re: Matching strings without repeated spaces
Message-Id: <1151030742.834929.129360@r2g2000cwb.googlegroups.com>
usenet@DavidFilmer.com wrote:
> I want to construct a regexp which will match a string containing only
> \w and \s, but not repeated whitespaces. I can do it (crudely) with
> two regexps, such as:
>
> if (/[\w\s-]+$/ && ! /\s\s/) {
>
> but I'd rather do it with a single regexp... but guessing at the syntax
> has not proved effective.
>
> I'd appreciate some insight...
>
> Thanks!
how about this
if (/^(?:\w\s?)*$/) { ... }
Xicheng
------------------------------
Date: 22 Jun 2006 20:11:44 -0700
From: robby.walker@gmail.com
Subject: Online Graphing Calculator - Perl Backend
Message-Id: <1151032304.745501.28850@m73g2000cwd.googlegroups.com>
Hi,
I've just released a full-featured online graphing calculator at
http://www.e-tutor.com/et2/graphing/ - the back end is built with
(mod_)Perl and GD.
It requires no downloads or plugins - just JavaScript. You can track
points on the curve, graph multiple functions, and more. I'm also
interested in hearing people's feature requests.
If you really like it, please consider digging it:
http://digg.com/software/Online_Graphing_Calculator_2
or voting for it on reddit.com
http://programming.reddit.com/new?n=all
Enjoy!
- Robby
------------------------------
Date: 22 Jun 2006 18:33:03 -0700
From: "janicehwang1325@yahoo.com" <janicehwang1325@yahoo.com>
Subject: Re: Running another program in daemon server
Message-Id: <1151026383.106135.272250@y41g2000cwy.googlegroups.com>
Thanks for all the information. It's true that i change the directory
to some other place when i run it as daemon. thank you very much.
janicehwang1325@yahoo.com wrote:
> hi,
>
> I came across a problem which is when i run the server program without
> the daemon code, calling another program by `perl second.pl` is just
> fine. However, when i put the server to be in daemon, calling to
> another program by using `perl <something>.pl` is not working anymore.
> What is the cause and how to solve?
>
> Thank you very much.
------------------------------
Date: 22 Jun 2006 19:24:21 -0700
From: "janicehwang1325@yahoo.com" <janicehwang1325@yahoo.com>
Subject: Re: Running another program in daemon server
Message-Id: <1151029461.078010.284990@b68g2000cwa.googlegroups.com>
The directory is changed to the root directory. However, i try to run
another program using `\path\to\perl \path\to\client.pl` still doesn't
work. is there any other solutions?
Josef Moellers wrote:
> janicehwang1325@yahoo.com wrote:
> > hi,
> >
> > I came across a problem which is when i run the server program without
> > the daemon code, calling another program by `perl second.pl` is just
> > fine. However, when i put the server to be in daemon, calling to
> > another program by using `perl <something>.pl` is not working anymore.
> > What is the cause and how to solve?
> >
> > Thank you very much.
> >
>
> Making a daemon occasionally involves changing the working directory
> (from the Linux manpage of the daemon() function):
>
> "Unless the argument nochdir is non-zero, daemon() changes the current
> working directory to the root ("/")."
>
> Check where you are.
>
> --
> Josef M=F6llers (Pinguinpfleger bei FSC)
> If failure had no penalty success would not be a prize
> -- T. Pratchett
------------------------------
Date: 22 Jun 2006 20:50:32 -0700
From: "janicehwang1325@yahoo.com" <janicehwang1325@yahoo.com>
Subject: Re: Running another program in daemon server
Message-Id: <1151034632.724696.19910@b68g2000cwa.googlegroups.com>
Hi,
Just to share with you, my problem is solved by just putting the
program in root directory. It might not be the best solution however,
it did solve my current headache. Anyhow, if there is another way to
solve it, please share with me. Thank you!
Josef Moellers wrote:
> janicehwang1325@yahoo.com wrote:
> > hi,
> >
> > I came across a problem which is when i run the server program without
> > the daemon code, calling another program by `perl second.pl` is just
> > fine. However, when i put the server to be in daemon, calling to
> > another program by using `perl <something>.pl` is not working anymore.
> > What is the cause and how to solve?
> >
> > Thank you very much.
> >
>
> Making a daemon occasionally involves changing the working directory
> (from the Linux manpage of the daemon() function):
>
> "Unless the argument nochdir is non-zero, daemon() changes the current
> working directory to the root ("/")."
>
> Check where you are.
>
> --
> Josef M=F6llers (Pinguinpfleger bei FSC)
> If failure had no penalty success would not be a prize
> -- T. Pratchett
------------------------------
Date: 22 Jun 2006 18:40:56 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151026856.064429.36460@c74g2000cwc.googlegroups.com>
Joe Marshall wrote:
>
> That's the important point: I want to run broken code.
I want to make sure I understand. I can think of several things
you might mean by this. It could be:
1) I want to run my program, even though I know parts of it
are broken, because I think there are parts that are not broken
and I want to try them out.
2) I want to run my program, even though it is broken, and I
want to run right up to a broken part and trap there, so I can
use the runtime facilities of the language to inspect what's
going on.
> I want to run
> as much of the working fragments as I can, and I want a `safety net' to
> prevent me from performing undefined operations, but I want the safety
> net to catch me at the *last* possible moment.
This statement is interesting, because the conventional wisdom (at
least as I'm used to hearing it) is that it is best to catch bugs
at the *first* possible moment. But I think maybe we're talking
about different continua here. The last last last possible moment
is after the software has shipped to the customer, and I'm pretty
sure that's not what you mean. I think maybe you mean something
more like 2) above.
Marshall
------------------------------
Date: 22 Jun 2006 18:56:40 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151027800.460188.116860@i40g2000cwc.googlegroups.com>
Joachim Durchholz wrote:
> Marshall schrieb:
> > immutable = can't change
> > vary-able = can change
> >
> > Clearly a contradiction in terms.
>
> Not in mathematics.
So stipulated.
However, it *is* a contradiction in English. Now, we often redefine
or narrow terms for technical fields. However, when we find
ourselves in a situation where we've inverted the English
meaning with the technical meaning, or ended up with a
contradiction, it ought to give us pause.
> The understanding there is that a "variable" varies - not over time, but
> according to the whim of the usage. (E.g. if a function is displayed in
> a graph, the parameter varies along the X axis. If it's used within a
> term, the parameter varies depending on how it's used. Etc.)
>
> Similarly for computer programs.
> Of course, if values are immutable, the value associated with a
> parameter name cannot vary within the same invocation - but it can still
> vary from one invocation to the next.
Again, stipulated. In fact I conceded this was a good point when it
was first mentioned. However, we generally refer to parameters
to functions as "parameters"-- you did it yourself above.
What we generally (in programming) call variables are locals
and globals. If the languages supports an update operation
on those variables, then calling them variables makes sense.
But "variable" has become such a catch-all term that we call
public static final int FOO = 7;
a variable, even though it can never, ever vary.
That doesn't make any sense.
If we care about precision in our terminology, we ought to
distinguish among parameters, named values that support
destructive update, named values that don't support
destructive update, and possibly other things.
Marshall
------------------------------
Date: 22 Jun 2006 19:03:34 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151028214.668765.182330@p79g2000cwp.googlegroups.com>
Timo Stamm wrote:
>
> This is actually one of the most interesting threads I have read in a
> long time. If you ignore the evangelism, there is a lot if high-quality
> information and first-hand experience you couldn't find in a dozen books.
Hear hear! This is an *excellent* thread. The evangelism is at
rock-bottom
and the open exploration of other people's way of thinking is at what
looks to me like an all-time high.
Marshall
------------------------------
Date: Thu, 22 Jun 2006 20:31:01 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f050051210205e29896e4@news.altopia.net>
Anton van Straaten wrote:
> Vesa Karvonen 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.
I agree that there's more to it than that. I also agree, however, that
Vesa's observation is true, and is a big part of the reason why it's
difficult to discuss this topic. I don't recall who said what at this
point, but earlier today someone else posted -- in this same thread --
the idea that static type "advocates" want to classify some languages as
untyped in order to put them in the same category as assembly language
programming. That's something I've never seen, and I think it's far
from the goal of pretty much anyone; but clearly, *someone* was
concerned about it. I don't know if much can be done to clarify this
rhetorical problem, but it does exist.
The *other* bit that's been brought up in this thread is that the word
"type" is just familiar and comfortable for programmers working in
dynamically typed languages, and that they don't want to change their
vocabulary.
The *third* thing that's brought up is that there is a (to me, somewhat
vague) conception going around that the two really ARE varieties of the
same thing. I'd like to pin this down more, and I hope we get there,
but for the time being I believe that this impression is incorrect. At
the very least, I haven't seen a good way to state any kind of common
definition that withstands scrutiny. There is always an intuitive word
involved somewhere which serves as an escape hatch for the author to
retain some ability to make a judgement call, and that of course
sabotages the definition. So far, that word has varied through all of
"type", "type error", "verify", and perhaps others... but I've never
seen anything that allows someone to identify some universal concept of
typing (or even the phrase "dynamic typing" in the first place) in a way
that doesn't appeal to intuition.
> 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.
Undoubtedly, some programmers sometimes perform reasoning about their
programs which could also be performed by a static type system. This is
fairly natural, since static type systems specifically perform tractable
analyses of programs (Pierce even uses the word "tractable" in the
definition of a type system), and human beings are often (though not
always) best-served by trying to solve tractable problems as well.
> 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.
Let me pipe up, then, as saying that I can't see those reasons; or at
least, if I am indeed seeing the same reasons that everyone else is,
then I am unconvinced by them that there's any kind of rigorous
connection at all.
> 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).
It is, nevertheless, quite appropriate to call the language "untyped" if
I am considering static type systems. I seriously doubt that this usage
in any way misleads anyone into assuming the absence of any mental
processes on the part of the programmer. I hope you agree. If not,
then I think you significantly underestimate a large category of people.
> 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.
I couldn't disagree more. Rather, when you're talking about static
types (or just "types" in most research literature that I've seen), then
the realm of discussion is specifically defined to be the very set of
errors that are automatically caught and flagged by the language
translator. I suppose that it is possible to have an unimplemented type
system, but it would be unimplemented only because someone hasn't felt
the need nor gotten around to it. Being implementABLE is a crucial part
of the definition of a static type system.
I am beginning to suspect that you're make the converse of the error I
made earlier in the thread. That is, you may be saying things regarding
the psychological processes of programmers and such that make sense when
discussing dynamic types, and in any case I haven't seen any kind of
definition of dynamic types that is more acceptable yet; but it's
completely irrelevant to static types. Static types are not fuzzy -- if
they were fuzzy, they would cease to be static types -- and they are not
a phenomenon of psychology. To try to redefine static types in this way
not only ignores the very widely accepted basis of entire field of
existing literature, but also leads to false ideas such as that there is
some specific definable set of problems that type systems are meant to
solve.
Skipping ahead a bit...
> I agree, to make the comparison perfect, you'd need to define a type
> system. But that's been done in various cases.
I don't think that has been done, in the case of dynamic types. It has
been done for static types, but much of what you're saying here is in
contradiction to the definition of a type system in that sense of the
word.
> The problem we're dealing with in this case is that anything that's not
> formally defined is essentially claimed to not exist.
I see it as quite reasonable when there's an effort by several
participants in this thread to either imply or say outright that static
type systems and dynamic type systems are variations of something
generally called a "type system", and given that static type systems are
quite formally defined, that we'd want to see a formal definition for a
dynamic type system before accepting the proposition that they are of a
kind with each other. So far, all the attempts I've seen to define a
dynamic type system seem to reduce to just saying that there is a well-
defined semantics for the language.
I believe that's unacceptable for several reasons, but the most
significant of them is this. It's not reasonable to ask anyone to
accept that static type systems gain their essential "type system-ness"
from the idea of having well-defined semantics. From the perspective of
a statically typed language, this looks like a group of people getting
together and deciding that the real "essence" of what it means to be a
type system is... and then naming something that's so completely non-
essential that we don't generally even mention it in lists of the
benefits of static types, because we have already assumed that it's true
of all languages except C, C++, and assembly language.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 22 Jun 2006 19:35:40 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151030140.202720.245140@y41g2000cwy.googlegroups.com>
Anton van Straaten wrote:
> 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.)
Thanks for the excellent followup.
> The short answer is that I'm most directly referring to "the types in
> the programmer's head".
In the database theory world, we speak of three levels: conceptual,
logical, physical. In a dbms, these might roughly be compared to
business entities described in a requirements doc, (or in the
business owners' heads), the (logical) schema encoded in the
dbms, and the b-tree indicies the dbms uses for performance.
So when you say "latent types", I think "conceptual types."
The thing about this is, both the Lisp and the Haskell programmers
are using conceptual types (as best I can tell.) And also, the
conceptual/latent types are not actually a property of the
program; they are a property of the programmer's mental
model of the program.
It seems we have languages:
with or without static analysis
with or without runtime type information (RTTI or "tags")
with or without (runtime) safety
with or without explicit type annotations
with or without type inference
Wow. And I don't think that's a complete list, either.
I would be happy to abandon "strong/weak" as terminology
because I can't pin those terms down. (It's not clear what
they would add anyway.)
> 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.
Uh, oh, a new term, "manifest." Should I worry about that?
> (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".
Well, darn. It strikes me that that's just a decision the language
designers
made, *not* to record complete RTTI. (Is it going to be claimed that
there is an *advantage* to having only incomplete RTTI? It is a
serious question.)
> 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.
Yes, function is a parameterized type, and they've left out the
parameter values.
> 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.
Gotcha.
> (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.
Hmmm. Another place where the static type isn't the same thing as
the runtime type occurs in languages with subtyping.
Question: if a language *does* record complete RTTI, and the
languages does *not* have subtyping, could we then say that
the runtime type information *is* the same as the static type?
Marshall
------------------------------
Date: Thu, 22 Jun 2006 20:46:10 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f0503ddb2da16769896e7@news.altopia.net>
Chris Smith <cdsmith@twu.net> wrote:
> I see it as quite reasonable when there's an effort by several
> participants in this thread to either imply or say outright that static
> type systems and dynamic type systems are variations of something
> generally called a "type system" [...]
I didn't say that right. Obviously, no one is making all that great an
EFFORT to say anything. Typing is not too difficult, after all. What I
meant is that there's an argument being made to that effect.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Fri, 23 Jun 2006 01:09:42 GMT
From: "register_allocation" <register_allocation@lycos.com>
Subject: Re: Why doesn't chdir (@args) work?
Message-Id: <qbHmg.10497$o4.4703@newsread2.news.pas.earthlink.net>
Tad McClellan <tadmc@augustmail.com> wrote in
news:slrne92nmh.3am.tadmc@magna.augustmail.com:
> Spurrious Umlaut <not-for-email@example.com> wrote:
>> "register_allocation" <register_allocation@lycos.com> wrote in
>> news:nP3kg.13122$921.10188@newsread4.news.pas.earthlink.net:
>>
>>> [...] Does chdir
>>> have a prototype?
>>
>> I figured it out. Looks like it's prototyped as chdir(;$),
>
>
> Which can be pretty easily observed by the 1st line of the chdir docs:
>
> chdir EXPR
>
> If it wanted a list, it would have been
>
> chdir LIST
I only recently read the documentation closely enough to find out that
the docs make this EXPR/LIST distinction.
> (which doesn't make much sense of course, you can't have
> multiple working directories.
> )
Well, the reason I wanted to do it was because I was playing around with a
shell-like Perl program, and I wanted to do something like
my @commandArgs = parse($commandLine);
my $builtIn = "builtIn_$commandArgs[0]";
if ($self->can($builtIn)) {
shift(@commandArgs);
$self->$builtIn(@commandArgs);
}
Then just write
sub builtIn_cd { shift; chdir @_; } # oops -- doesn't work :-(
Oh, well. It isn't that big a deal to parse out the 0/1/too many arg case.
------------------------------
Date: Thu, 22 Jun 2006 21:18:27 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: Why doesn't chdir (@args) work?
Message-Id: <m2lkrooejg.fsf@Sherm-Pendleys-Computer.local>
"register_allocation" <register_allocation@lycos.com> writes:
> Well, the reason I wanted to do it was because I was playing around with a
> shell-like Perl program
Were you aware that such a beast already exists? It looks like it hasn't seen
much activity in quite a while - the developer might be happy to get some help.
<http://sourceforge.net/projects/psh/>
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Thu, 22 Jun 2006 21:05:11 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Why doesn't chdir (@args) work?
Message-Id: <slrne9mj2n.6h0.tadmc@magna.augustmail.com>
register_allocation <register_allocation@lycos.com> wrote:
> Tad McClellan <tadmc@augustmail.com> wrote in
> news:slrne92nmh.3am.tadmc@magna.augustmail.com:
>
>> Spurrious Umlaut <not-for-email@example.com> wrote:
>>> "register_allocation" <register_allocation@lycos.com> wrote in
>>> news:nP3kg.13122$921.10188@newsread4.news.pas.earthlink.net:
>>>
>>>> [...] Does chdir
>>>> have a prototype?
>>>
>>> I figured it out. Looks like it's prototyped as chdir(;$),
>>
>>
>> Which can be pretty easily observed by the 1st line of the chdir docs:
>>
>> chdir EXPR
>>
>> If it wanted a list, it would have been
>>
>> chdir LIST
>
> I only recently read the documentation closely enough to find out that
> the docs make this EXPR/LIST distinction.
Then you better stop programming right away and read the "Context"
section in:
perldoc perldata
Just about every function in Perl has *two* behaviors, one behavior
when it is called in scalar context, and another when it is called
in list context.
The EXPR/LIST annotation is how you can tell what context a function
will put on its arguments (scalar/list).
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 9349
***************************************
