[27963] in Perl-Users-Digest
Perl-Users Digest, Issue: 9327 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 20 18:10:15 2006
Date: Tue, 20 Jun 2006 15:10:07 -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 Tue, 20 Jun 2006 Volume: 10 Number: 9327
Today's topics:
Re: What is Expressiveness in a Computer Language <yumagene@gmail.com>
Re: What is Expressiveness in a Computer Language <dnew@san.rr.com>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
Re: What's ^$ mean? smarkham01@yahoo.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 20 Jun 2006 11:11:15 -0700
From: "genea" <yumagene@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150827075.175209.8800@i40g2000cwc.googlegroups.com>
Joe Marshall wrote:
{...}
> The issue of `static vs. dynamic types' comes up about twice a year in
> comp.lang.lisp It generally gets pretty heated, but eventually people
> come to understand what the other person is saying (or they get bored
> and drop out of the conversation - I'm not sure which). {...}
I think that the thing about "Language Expressiveness" is just so
elusive, as it is based on each programmers way of thinking about
things, and also the general types of problems that that programmer is
dealing with on a daily basis. There are folks out there like the Paul
Grahams of the world, that do wonderfully complex things in Lisp,
eschew totally the facilities of the CLOS, the lisp object system, and
get the job done ... just because they can hack and have a mind picture
of what all the type matches are "in there head". I used to use forth,
where everything goes on a stack, and it is up to the programmer to
remember what the heck the type of a thing was that was stored there...
maybe an address of a string, another word {read function}, or an
integer... NO TYPING AT ALL, but can you be expressive in forth... You
can if you are a good forth programmer... NOW that being said, I think
that the reason I like Haskell, a very strongly typed language, is that
because of it's type system, the language is able to do things like
lazy evaluation, and then though it is strongly typed, and has
wonderful things like type classes, a person can write wildly
expressive code, and NEVER write a thing like:
fromtoby :: forall b a.
(Num a, Enum a) =>
a -> a -> a -> (a -> b) -> [b]
The above was generated by the Haskell Compiler for me... and it does
that all the time, without any fuss. I just wrote the function and it
did the rest for me... By the way the function was a replacement for
the { for / to / by } construct of like a C language and it was done in
one line... THAT TO ME IS EXPRESSIVE, when I can build whole new
features into my language in just a few lines... usually only one
line.. I think that is why guys who are good to great in dynamic or
if it floats your boat, type free languages like Lisp and Scheme find
their languages so expressive, because they have found the macro's or
whatever else facility to give them the power... to extend their
language to meet a problem, or fit maybe closer to an entire class of
problems.. giving them the tool box.. Haskeller', folks using Ruby,
Python, ML, Ocaml, Unicon.... even C or whatever... By building either
modules, or libraries... and understand that whole attitude of tool
building.. can be equally as expressive "for their own way of doing
things". Heck, I don't use one size of hammer out in my workshop, and
I sure as hell don't on my box... I find myself picking up Icon and
it's derivative Unicon to do a lot of data washing chores.. as it
allows functions as first class objects... any type can be stored in a
list... tables... like a hash ... with any type as the data and the
key... you can do things like
i := 0
every write(i+:=1 || read())
which will append a sequence of line numbers to the lines read in from
stdin.. pretty damn concise and expressive in my book... Now for other
problems .. Haskell with it's single type lists... which of course can
have tuples, which themselves have tuples in them with a list as one
element of that tuple... etc.. and you can build accessors for all of
that for function application brought to bear on one element of one
tuple allowing mappings of that function to all of that particular
element of ... well you get the idea.. It is all about how you see
things and how your particular mindset is... I would agree with
someone that early on in the discussion said the thing about "type's
warping your mind" and depending on the individual, it is either a good
warp or a bad warp, but that is why there is Ruby and Python, and
Haskell and even forth... for a given problem, and a given programmer,
any one of those or even Cobol or Fortran might be the ideal tool... if
nothing else based on that persons familiarity or existing tool and
code base.
enough out of me...
-- gene
------------------------------
Date: Tue, 20 Jun 2006 18:19:40 GMT
From: Darren New <dnew@san.rr.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <0%Wlg.3521$MF6.947@tornado.socal.rr.com>
Chris Uppal wrote:
> 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. For example,
it makes very clear the difference between a value of (type T) and a
value of (type T or one of its subtypes).
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
------------------------------
Date: Tue, 20 Jun 2006 13:28:24 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m164ivhebb.fsf@hana.uchicago.edu>
"Rob Thorpe" <robert.thorpe@antenova.com> writes:
> I think we're discussing this at cross-purposes. In a language like C
> or another statically typed language there is no information passed
> with values indicating their type.
You seem to be confusing "does not have a type" with "no type
information is passed at runtime".
> Have a look in a C compiler if you don't believe me.
Believe me, I have.
> No it doesn't. Casting reinterprets a value of one type as a value of
> another type.
> There is a difference. If I cast an unsigned integer 2000000000 to a
> signed integer in C on the machine I'm using then the result I will get
> will not make any sense.
Which result are you getting? What does it mean to "make sense"?
------------------------------
Date: Tue, 20 Jun 2006 20:28:50 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4fqt33F1kfd1jU1@individual.net>
Rob Thorpe wrote:
> Pascal Costanza wrote:
>> Matthias Blume wrote:
>>> Pascal Costanza <pc@p-cos.net> writes:
>>>> (slot-value p 'address) is an attempt to access the field 'address in
>>>> the object p. In many languages, the notation for this is p.address.
>>>>
>>>> Although the class definition for person doesn't mention the field
>>>> address, the call to (eval (read)) allows the user to change the
>>>> definition of the class person and update its existing
>>>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>>>> has a chance to succeed.
>>> I am quite comfortable with the thought that this sort of evil would
>>> get rejected by a statically typed language. :-)
>> This sort of feature is clearly not meant for you. ;-P
>
> To be fair though that kind of thing would only really be used while
> debugging a program.
> Its no different than adding a new member to a class while in the
> debugger.
>
> There are other places where you might add a slot to an object at
> runtime, but they would be done in tidier ways.
Yes, but the question remains how a static type system can deal with
this kind of updates.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Tue, 20 Jun 2006 14:40:00 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f020af6425675b19896d0@news.altopia.net>
Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
> > I'm unsure whether to consider explicitly stored array lengths, which
> > are present in most statically typed languages, to be part of a "type"
> > in this sense or not.
>
> If I understand your position correctly, wouldn't you be pretty much forced to
> reject the idea of the length of a Java array being part of its type ?
I've since abandoned any attempt to be picky about use of the word
"type". That was a mistake on my part. I still think it's legitimate
to object to statements of the form "statically typed languages X, but
dynamically typed languages Y", in which it is implied that Y is
distinct from X. When I used the word "type" above, I was adopting the
working definition of a type from the dynamic sense. That is, I'm
considering whether statically typed languages may be considered to also
have dynamic types, and it's pretty clear to me that they do.
> If you
> want to keep the word "type" bound to the idea of static analysis, then --
> since Java doesn't perform any size-related static analysis -- the size of a
> Java array cannot be part of its type.
Yes, I agree. My terminology has been shifting constantly throughout
this thread as I learn more about how others are using terms. I realize
that probably confuses people, but my hope is that this is still
superior to stubbornly insisting that I'm right. :)
> That's assuming that you would want to keep the "type" connected to the actual
> type analysis performed by the language in question. Perhaps you would prefer
> to loosen that and consider a different (hypothetical) language (perhaps
> producing identical bytecode) which does do compile time size analysis.
In the static sense, I think it's absolutely critical that "type" is
defined in terms of the analysis done by the type system. Otherwise,
you miss the definition entirely. In the dynamic sense, I'm unsure; I
don't have any kind of deep understanding of what's meant by "type" in
this sense. Certainly it could be said that there are somewhat common
cross-language definitions of "type" that get used.
> But then you get into an area where you cannot talk of the type of a value (or
> variable) without relating it to the specific type system under discussion.
Which is entirely what I'd expect in a static type system.
> Personally, I would be quite happy to go there -- I dislike the idea that a
> value has a specific inherent type.
Good! :)
> It would be interesting to see what a language designed specifically to support
> user-defined, pluggable, and perhaps composable, type systems would look like.
> Presumably the syntax and "base" semantics would be very simple, clean, and
> unrestricted (like Lisp, Smalltalk, or Forth -- not that I'm convinced that any
> of those would be ideal for this), with a defined result for any possible
> sequence of operations. The type-system(s) used for a particular run of the
> interpreter (or compiler) would effectively reduce the space of possible
> sequences. For instance, one could have a type system which /only/ forbade
> dereferencing null, or another with the job of ensuring that mutability
> restrictions were respected, or a third which implemented access control...
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.
> But then, I don't see a semantically critically distinction between such space
> reduction being done at compile time vs. runtime. Doing it at compile time
> could be seen as an optimisation of sorts (with downsides to do with early
> binding etc). That's particularly clear if the static analysis is /almost/
> able to prove that <some sequence> is legal (by its own rules) but has to make
> certain assumptions in order to construct the proof. In such a case the
> compiler might insert a few runtime checks to ensure that it's assumptions were
> valid, but do most of its checking statically.
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.
You mention static typing above as an optimization to dynamic typing;
that is certainly one possible applications of these theorems.
In some sense, though, it is interesting in its own right to know that
these theorems have been proven. Of course, there are important doubts
to be had whether these are the theorems we wanted to prove in the first
place, and whether the effort of proving them was worth the additional
confidence I have in my software systems.
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.
(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.)
In the end, though, I'm just not very interested in them at the moment.
For me, as a practical matter, choices of programming language are
generally dictated by more practical considerations. I do basically all
my professional "work" development in Java, because we have a gigantic
existing software system written in Java and no time to rewrite it. 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.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 20 Jun 2006 13:24:40 -0700
From: smarkham01@yahoo.com
Subject: Re: What's ^$ mean?
Message-Id: <1150835080.551808.47180@g10g2000cwb.googlegroups.com>
I don't disagree with your definition Tadd, but I'm curious as to what
meaning, other than "at the beginning of the (string | line) match the
end of (string | line)" "^$" might have? Don't meta-characters remain
remain meta-characters where ever they are, unless escaped of preceded
by \Q?
Tad McClellan wrote:
> Nick of course <mol10metal@hotmail.com> wrote:
> > Mirco Wahab wrote:
>
> [snip full-quote]
>
> > A slightly shorter answer to the original question would have been "Yes"
>
>
> That would have been a slightly shorter *wrong* answer.
>
> (Since it will match when the string is "\n".)
>
> The original (poorly phrased) question was:
>
> Is ^$ mean a NULL line?
>
> The OP didn't say where these characters are used. I'll guess they
> are used with the pattern match operator.
>
> What does "NULL line" mean?
>
> I assume it means the "empty string" (in which case it cannot be
> a "line" since it has no newline character).
>
> So if a boolean response is required then "No" would be the accurate answer.
>
> A more helpful answer would be:
>
> /^$/ matches the empty string, or the 1-char long string where
> the 1 char is a newline.
>
>
> --
> 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 9327
***************************************
