fileinput

[Pascal]

I have a small python (3.7.4) script that should open a log file and
display its content but as you can see, an encoding error occurs :

---

import fileinput
import sys
try:
source = sys.argv[1:]
except IndexError:
source = None
for line in fileinput.input(source):
print(line.strip())

---

python3.7.4 myscript.py myfile.log
Traceback (most recent call last):
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
invalid continuation byte

python3.7.4 myscript.py < myfile.log
Traceback (most recent call last):
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
invalid continuation byte

---

I add the encoding hook to overcome the error but this time, the script
reacts differently depending on the input used :

---

import fileinput
import sys
try:
source = sys.argv[1:]
except IndexError:
source = None
for line in fileinput.input(source,
openhook=fileinput.hook_encoded("utf-8", "ignore")):
print(line.strip())

---

python3.7.4 myscript.py myfile.log
first line of myfile.log
...
last line of myfile.log

python3.7.4 myscript.py < myfile.log
Traceback (most recent call last):
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
invalid continuation byte

python3.7.4 myscript.py /dev/stdin < myfile.log
first line of myfile.log
...
last line of myfile.log

python3.7.4 myscript.py - < myfile.log
Traceback (most recent call last):
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 799:
invalid continuation byte

---

does anyone have an explanation and/or solution ?
-- 
https://mail.python.org/mailman/listinfo/python-list

sudo python PermissionError [Errno 13] Permission denied

[Pascal]

hi,

here, I have this simple script that tests if the /tmp/test file can be
opened in write mode :

$ cat /tmp/append
#!/usr/bin/python
with open('/tmp/test', 'a'): pass

the file does not exist yet :

$ chmod +x /tmp/append
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory

the script is launched as a simple user :

$ /tmp/append
$ ls -l /tmp/test
-rw-r--r-- 1 user user 0 Dec 17 10:30 /tmp/test

everything is ok.
now, the script fails if it is replayed as root user with the sudo command :

$ sudo /tmp/append
[sudo] password for user:
Traceback (most recent call last):
  File "/tmp/append", line 2, in 
with open('/tmp/test', 'a'):
PermissionError: [Errno 13] Permission denied: '/tmp/test'

the problem is the same if the opening mode is 'w' or if "sudo -i" or "su -"
are used.

why can't root user under python manipulate the simple user file ?

regards, lacsaP.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sudo python PermissionError [Errno 13] Permission denied

[Pascal]

you are right !

the "sticky bit" set to /tmp/ prevents the root user from altering the file
belonging to the simple user !

$ ls -ld /tmp/
drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/

$ ls -l /tmp/test
-rw-r--r-- 1 user 0 Dec 17 13:24 /tmp/test

$ echo test | sudo tee -a /tmp/test
tee: /tmp/test: Permission denied
test

but it does not prevent its deletion !

$ sudo rm -v /tmp/test
removed '/tmp/test'.

which misled me : sorry for the waste of time.

happy end of year 2020, lacsaP.

Le jeu. 17 déc. 2020 à 13:09, <2qdxy4rzwzuui...@potatochowder.com> a écrit :

> On 2020-12-17 at 11:17:37 +0100,
> Pascal  wrote:
>
> > hi,
> >
> > here, I have this simple script that tests if the /tmp/test file can be
> > opened in write mode :
> >
> > $ cat /tmp/append
> > #!/usr/bin/python
> > with open('/tmp/test', 'a'): pass
> >
> > the file does not exist yet :
> >
> > $ chmod +x /tmp/append
> > $ ls -l /tmp/test
> > ls: cannot access '/tmp/test': No such file or directory
> >
> > the script is launched as a simple user :
> >
> > $ /tmp/append
> > $ ls -l /tmp/test
> > -rw-r--r-- 1 user user 0 Dec 17 10:30 /tmp/test
> >
> > everything is ok.
> > now, the script fails if it is replayed as root user with the sudo
> command :
> >
> > $ sudo /tmp/append
> > [sudo] password for user:
> > Traceback (most recent call last):
> >   File "/tmp/append", line 2, in 
> > with open('/tmp/test', 'a'):
> > PermissionError: [Errno 13] Permission denied: '/tmp/test'
> >
> > the problem is the same if the opening mode is 'w' or if "sudo -i" or
> "su -"
> > are used.
> >
> > why can't root user under python manipulate the simple user file ?
>
> This has to do with the idiosyncratic permissions of the /tmp directory
> and not your code.  In my shell on my Linux box:
>
> $ rm -f /tmp/x
> $ echo x >/tmp/x
> $ echo x | sudo tee /tmp/x
> tee: /tmp/x: Permission denied
> x
>
> $ ls -ld /tmp
> drwxrwxrwt 13 root root 380 Dec 17 06:03 /tmp
>
> Try your experiment in a different directory, one without the sticky bit
> set.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Py2exe-users] py2exe 0.6.9 released

[Pascal]

On Mon, 17 Nov 2008 12:39:36 +, Pascal wrote:

> On Sun, 16 Nov 2008 21:23:59 -0500, Chris Spencer wrote:
> 
>> After I "compile" my program with py2exe 0.6.9 with Python 2.6, I'm
>> still getting the "Application Did Not Initialize Properly" error
>> dialog whenever I run my code.  What am I doing wrong?
> 
> I have exactly the same problem.
> I have tried just anything I could think of to no avail : Copied the 3
> msvc_90.dll to the system32 subdir of Windows, to the directory of my
> application, reinstalled the whole Microsoft Visual C++ 2008
> Redistributable Package, embedded the manifest data into the exe or kept
> it in a .manifest file...
> Could not make it work. Always got the "Application Did Not Initialize
> Properly" message.
> I'm with Windows XP SP3. I tried all this on 2 different systems and I
> got the same results.


I think I narrowed down a little bit the problem. It's not the common one 
when the msvc_90.dll are not located, though the result is similar.
The problem is when you try to generate at least 2 exe in one setup (with 
2 scripts specified in the "windows" command of the setup).
This works OK with py2exe 0.6.9 for Python 2.5, but fails with Python 2.6 
(and 2.6.1). None of the generated exe can be started.
When I compare the content of library.zip in both versions, this file 
doesn't contain any .pyc for the scripts you want to generate an exe for 
with Python 2.5, but always contains a .pyc for one of the scripts you 
want to generate an .exe for with Python 2.6. Don't know if it's a clue 
for finding a fix.
I have tested many ways to figure this out but I can't find any solution 
for the moment so I'm sticking with Python 2.5.
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Py2exe-users] py2exe 0.6.9 released

[Pascal]

On Mon, 08 Dec 2008 14:47:13 +, Pascal wrote:

> On Mon, 17 Nov 2008 12:39:36 +0000, Pascal wrote:
> 
>> On Sun, 16 Nov 2008 21:23:59 -0500, Chris Spencer wrote:
>> 
>>> After I "compile" my program with py2exe 0.6.9 with Python 2.6, I'm
>>> still getting the "Application Did Not Initialize Properly" error
>>> dialog whenever I run my code.  What am I doing wrong?
>> 
>> I have exactly the same problem.
>> I have tried just anything I could think of to no avail : Copied the 3
>> msvc_90.dll to the system32 subdir of Windows, to the directory of my
>> application, reinstalled the whole Microsoft Visual C++ 2008
>> Redistributable Package, embedded the manifest data into the exe or
>> kept it in a .manifest file...
>> Could not make it work. Always got the "Application Did Not Initialize
>> Properly" message.
>> I'm with Windows XP SP3. I tried all this on 2 different systems and I
>> got the same results.
> 
> 
> I think I narrowed down a little bit the problem. It's not the common
> one when the msvc_90.dll are not located, though the result is similar.
> The problem is when you try to generate at least 2 exe in one setup
> (with 2 scripts specified in the "windows" command of the setup). This
> works OK with py2exe 0.6.9 for Python 2.5, but fails with Python 2.6
> (and 2.6.1). None of the generated exe can be started. When I compare
> the content of library.zip in both versions, this file doesn't contain
> any .pyc for the scripts you want to generate an exe for with Python
> 2.5, but always contains a .pyc for one of the scripts you want to
> generate an .exe for with Python 2.6. Don't know if it's a clue for
> finding a fix.
> I have tested many ways to figure this out but I can't find any solution
> for the moment so I'm sticking with Python 2.5.

Got it !
If you want to generate an exe for a script of your own named abc.py, 
rename it because this will never work with that original name. The 
reason seems to be an abc.pyc file compiled by default by Python 2.6 and 
included in library.zip (abc stands in this case for "Abstract Base 
Classes"), and using this name for your own script makes nothing work ! 
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Py2exe-users] py2exe 0.6.9 released

[Pascal]

On Sun, 16 Nov 2008 21:23:59 -0500, Chris Spencer wrote:

> After I "compile" my program with py2exe 0.6.9 with Python 2.6, I'm
> still getting the "Application Did Not Initialize Properly" error dialog
> whenever I run my code.  What am I doing wrong?

I have exactly the same problem.
I have tried just anything I could think of to no avail : Copied the 3 
msvc_90.dll to the system32 subdir of Windows, to the directory of my 
application, reinstalled the whole Microsoft Visual C++ 2008 
Redistributable Package, embedded the manifest data into the exe or kept 
it in a .manifest file...
Could not make it work. Always got the "Application Did Not Initialize 
Properly" message.
I'm with Windows XP SP3. I tried all this on 2 different systems and I 
got the same results.

If anyone can give some help...
--
http://mail.python.org/mailman/listinfo/python-list

openmp do loops

[Pascal]

Hi,

I would like to parallelize this loop:
do i=1,hklsize
fcalctable(i)=structfact(hkltable(1,i),hkltable(2,i),hkltable(3,i))
end do


I thought I would do this:
!$OMP PARALLEL DO default(private) shared(hkltable, fcalctable,hklsize)
do i=1,hklsize
fcalctable(i)=structfact(hkltable(1,i),hkltable(2,i),hkltable(3,i))
end do
!$OMP END PARALLEL DO

However it seems that the order of the final table is not guarantee 
compared to the serial version. I need a j element of the table to stay 
there because I have an other table and I am using the index to match 
the data.


Regards,
Pascal
--
http://mail.python.org/mailman/listinfo/python-list

Re: openmp do loops

[Pascal]

On 11/04/2010 11:13 AM, Pascal wrote:

Hi,



Oops, wrong group, sorry...

Pascal
--
http://mail.python.org/mailman/listinfo/python-list

Re: Open Source: you're doing it wrong - the Pyjamas hijack

[Pascal Chambon]

Hi,

cool down, people, if anything gave FOSS a bad reputation, that's well 
the old pyjamas website (all broken, because "wheel must be reinvented 
here"), and most of all the "terror management" that occurred on its 
mailing list.
Previously I had always considered open-source as a benevolent state of 
mind, until I got, there, the evidence that it could also be, for some 
people, an irrational and harmful cult (did you know github were 
freaking evildoers ?).


Blatantly the pyjs ownership  change turned out to be an awkward 
operation (as reactions on that ML show it), but a fork could also have 
very harmfully "split" pyjs-interested people, so all in all I don't 
think there was a perfect solution - dictatorships never fall harmlessly.


The egos of some might have been hurt, the legal sense of others might 
have been questioned, but believe me all this fuss is pitiful compared 
to the real harm that was done numerous time to willing newcomers, on 
pyjs' old ML, when they weren't aware about the heavy dogmas lying around.


A demo sample  (I quote it each time the suvject arises, sorry for 
duplicates)


| Please get this absolutely clear in your head: that  |
| you do not "understand" my reasoning is completely and utterly   |
| irrelevant.  i understand *your* reasoning; i'm the one making the   |
| decisions, that's my role to understand the pros and cons.  i make a |
| decision: that's the end of it.  |
| You present reasoning to me: i weight it up, against the other   |
| reasoning, and i make a decision.  you don't have to understand that |
| decision, you do not have to like that decision, you do not have to  |
| accept that decision.|


Ling live pyjs,
++
PKL



Le 08/05/2012 07:37, alex23 a écrit :

On May 8, 1:54 pm, Steven D'Aprano  wrote:

Seriously, this was a remarkably ham-fisted and foolish way to "resolve"
a dispute over the direction of an open source project. That's the sort
of thing that gives open source a bad reputation.

The arrogance and sense of entitlement was so thick you could choke on
it. Here's a sampling from the circle jerk of self-justification that
flooded my inbox over the weekend:

"i did not need to consult Luke, nor would that have be productive"

No, it's generally _not_ productive to ask someone if you can steal
their project from them.

"i have retired Luke of the management duties, particularly, *above*
the source"

Who is this C Anthony Risinger asshole and in what way did he _hire_
the lead developer?

"What I have wondered is, what are effects of having the project
hostage to the whims of an individuals often illogically radical
software libre beliefs which are absolutely not up for discussion at
all with anyone."

What I'm wondering is: how is the new set up any different? Why were
Luke Leighton's philosophies/"whims" any more right or wrong than
those held by the new Gang of Dicks?

"Further more, the reason I think it's a bad idea to have this drawn
out discussion is that pretty much the main reason for this fork is
because of Luke leadership and project management decisions and
actions. To have discussions of why the fork was done would invariably
lead to quite a bit of personal attacks and petty arguments."

Apparently it's nicer to steal someone's work than be mean to them.

"I agree, Lex - this is all about moving on.  This is a software
project, not a cult of personality."

Because recognising the effort of the lead developer is cult-like.

"My only quibble is with the term "fork."  A fork is created when you
disagree with the technical direction of a project.  That's not the
issue here.  This is a reassignment of the project administration only
- a shuffling of responsibility among *current leaders* of the
community.  There is no "divine right of kings" here."

My quibble is over the term "fork" too, as this is outright theft. I
don't remember the community acknowledging _any other leadership_ over
Luke Leighton's.

"I suspect Luke will be busy with other projects and not do much more
for Pyjamas/pyjs, Luke correct me if you see this and I am wrong."

How about letting the man make his own fucking decisions?

"All of you spamming the list with your unsubscribe attempts: Anthony
mentioned in a previous email that he's using mailman now"

Apparently it's the responsibility of the person who was subscribed
without their permission to find out the correct mechanism for
unsubscribing from that list.

"apparantly a bunch of people were marked as "POSTING" in the DB, but
not receiving mail (?)"

Oh I see, the sudden rush of email I received was due to an error in
the data they stole...

"Nobody wins if we spend any amount of time debating the details of
this transition, what's done is done."

Truly the jus

Re: GIL in alternative implementations

[Pascal Chambon]

Thanks for the details on IronPython's implementation B-)

Hopefully Pypy will eventually get rid of its own Gil, since it doesn't 
do refcounting either.


Regards,
Pascal

Le 28/05/2011 00:52, Dino Viehland a écrit :


In IronPython we have fine grained locking on our mutable data 
structures.  In particular we have a custom dictionary type which is 
designed to allow lock-free readers on common operations while writers 
take a lock.  Our list implementation is similar but in some ways 
that's trickier to pull off due to features like slicing so if I 
recall correctly we only have lock-free reads when accessing a single 
element.


For .NET data structures they follow the .NET convention which is up 
to the data structure.  So if you wanted to get every last bit of 
performance out of your app you could handle thread safety yourself 
and switch to using the .NET dictionary or list types (although 
they're a lot less friendly to Python developers).


Because of these locks on micro-benchmarks that involve simple 
list/dict manipulations you do see noticeably worse performance in 
IronPython vs. CPython. 
http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf&referringTitle=IronPython%20Performance 
<http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf&referringTitle=IronPython%20Performance> 
 - See the SimpleListManipulation and SimpleDictManipulation as the 
core examples here.  Also CPython's dictionary is so heavily tuned 
it's hard to beat anyway, but this is a big factor.


Finally one of the big differences with both Jython and IronPython is 
that we have good garbage collectors which don't rely upon reference 
counting.  So one area where CPython gains from having a GIL is a 
non-issue for us as we don't need to protect ref counts or use 
interlocked operations for ref counting.


*From:* python-list-bounces+dinov=exchange.microsoft@python.org 
[mailto:python-list-bounces+dinov=exchange.microsoft@python.org] 
*On Behalf Of *Pascal Chambon

*Sent:* Friday, May 27, 2011 2:22 PM
*To:* python-list@python.org >> Python List
*Subject:* GIL in alternative implementations

Hello everyone,

I've already read quite a bit about the reasons for the GIL in 
CPython, i.e to summarize, that a more-fine graine locking, allowing 
real concurrency in multithreaded applications, would bring too much 
overhead for single-threaded python applications.


However, I've also heard that other python implementations 
(ironpython, jython...) have no GIL, and yet nobody blames them for 
performance penalties that would be caused by that lack (I especially 
think about IronPython, whose performances compare quite well to CPython).


So I'd like to know: how do these other implementations handle 
concurrency matters for their primitive types, and prevent them from 
getting corrupted in multithreaded programs (if they do) ? I'm not 
only thinking about python types, but also primitive containers and 
types used in .Net and Java VMs, which aren't atomic elements either 
at an assembly-level point of view.


Do these VMs have some GIL-like limitations, that aren't spoken about 
? Are there functionings completely different from the CPython VM, so 
that the question is not relevant ? Do people consider that they 
always concern multithreaded applications, and so accept performance 
penalties that they wouldn't allow in their CPython scripts ?


I think you in advance for your lights on these questions.

Regards,

Pkl

[[ Important Note: this is a serious question, trolls and emotionally 
disturbed persons had better go on their way. ]]




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Perl-Python-a-Day: Sorting

[Pascal Costanza]

Ulrich Hobelmann wrote:
> Xah Lee wrote:
> 
>> To sort a list in Python, use the “sort” method. For example:
>>
>> li=[1,9,2,3];
>> li.sort();
>> print li;
> 
> Likewise in Common Lisp.  In Scheme there are probably packages for that 
> as well.  My apologies for not being very fluent anymore.
> 
> CL-USER> (setf list (sort '(1 9 2 3) #'<)); input
> (1 2 3 9); output

Careful. Common Lisp's sort function is specified to be destructive, so 
you shouldn't use it on literal constants. So don't say (sort '(1 9 2 3) 
...), say (sort (list 1 9 2 3) ...), etc.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
 see http://p-cos.net/oopsla05-tutorial.html for more details 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[Pascal Bourguignon]

Roedy Green <[EMAIL PROTECTED]> writes:
> 3. You don't have to guess what the end user will see.

If you include the fonts, which makes big documents which slows down
the loading and rendering...  I've seen quite a number of PDF that are
ill-rendered or not rendered at all.

-- 
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can python 'read disk sectors' like/via linux:dd ?

[Pascal Bourguignon]

[EMAIL PROTECTED] writes:

> Hi,
> in order to justify learning another language I'd first need to be convinced 
> that python could easily do the following:-
>
>   ReadSectors2Bufr(hdx, StartSectr, SectrCnt, Bufr); <-- like linux: dd
>   PrintDecOf4Bytes(Offset, Bufr);  <-- and also 1 and 2 byte values
>   OverWriteBufr(Offset, Bufr, Byte);
>   WriteBufr2Sectors . <-- like linux: dd
>
> I guess one would normally use bash, but I'd rather invest effort
> in python if it can do this.
>
> Thanks for any info.

In unix, disks are files like any other file.  So if your programming
language allows you to read and write files, it allows you to read and
write disks.

Just write the equivalent of:

  int fd=open("/dev/hda",O_RDWR,0);
  if(0<==fd){
  check_errors(lseek(fd,SECT_SIZE*sect_num,SEEK_SET));
  check_errors(read(fd,buffer,SECT_SIZE));
  modify(buffer);
  check_errors(lseek(fd,SECT_SIZE*sect_num,SEEK_SET));
  check_errors(write(fd,buffer,SECT_SIZE)); 
  close(fd); }

and be sure to have the access rights on /dev/hda (and to know what
you're doing!).

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can python 'read disk sectors' like/via linux:dd ?

[Pascal Bourguignon]

Tauno Voipio <[EMAIL PROTECTED]> writes:

> Pascal Bourguignon wrote:
>
>> In unix, disks are files like any other file.  So if your programming
>> language allows you to read and write files, it allows you to read and
>> write disks.
>> Just write the equivalent of:
>>   int fd=open("/dev/hda",O_RDWR,0);
>>   if(0<==fd){
>>   check_errors(lseek(fd,SECT_SIZE*sect_num,SEEK_SET));
>>   check_errors(read(fd,buffer,SECT_SIZE));
>>   modify(buffer);
>>   check_errors(lseek(fd,SECT_SIZE*sect_num,SEEK_SET));
>>   check_errors(write(fd,buffer,SECT_SIZE));   close(fd); }
>> and be sure to have the access rights on /dev/hda (and to know what
>> you're doing!).
>
> This means in practice that your program has to run
> with root rights to handle complete disks or partitions.

Not necessarily.  We can see things like: chown oracle /dev/hdc

> Are you attempting to create a boot block virus?

I suppose that's what he is, in python...

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Xah's Edu Corner: Examples of Quality Technical Writing

[Pascal Bourguignon]

"Xah Lee" <[EMAIL PROTECTED]> writes:

> i had the pleasure to read the PHP's manual today.
>
> http://www.php.net/manual/en/
>
> although Pretty Home Page is another criminal hack of the unix lineage,
> but if we are here to judge the quality of its documentation, it is a
> impeccability.
>
> it has or possesses properties of:
>
> • To the point and useful.
>
>   PHP has its roots in mundaness, like Perl and Apache. Its doc being
> practicality oriented isn't a surprise, as are the docs of Perl and
> Apache.
>
> • Extreme clarity!

Do you have an "Approved by Xah Lee" seal logo they could put on their web page?

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what's OOP's jargons and complexities?

[Pascal Bourguignon]

"Larry" <[EMAIL PROTECTED]> writes:

> Xah Lee wrote:
> > in computer languages, often a function definition looks like this:
> 
> >  [EMAIL PROTECTED]
> >  http://xahlee.org/PageTwo_dir/more.html
> 
> Your ideas are original, insightful and simply reflect incredibly deep
> creative genius.  I have read your work and I want to hire you for
> highly classified work in software design and philosophical writing.
> Would you possibly be available to meet with me in my secret mountain
> compound to discuss terms?
> 
> Larry

You forgot to mention the coordinates of your secret mountain compound: 

   28 deg 5 min N, 86 deg 58 min E


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp-likeness

[Pascal Costanza]

Marcin 'Qrczak' Kowalczyk wrote:
[EMAIL PROTECTED] (Thomas A. Russ) writes:

(defun addn (n)
  #'(lambda (x)
  (+ x n)))
The same as 
def addn(n):
	def fn(x):
		return n + x
	return fn
Is this really equivalent?
What happens if you call addn more than once with different
parameters.  Will you get different functions that you can
use simultaneously?

Yes.
It also behaves correctly when a variable it refers to is later
mutated.
BTW, the fact that a closure refers to a variable itself rather to its
current value can be used to check the true attitude of languages with
respect to functional programming, by observing how they understand
their basic loops :-)
None of the examples you show close over values. The difference is in 
whether the loop constructs use one binding for their control variable 
or create new bindings in each iteration:

(loop for i below 10
  collect (lambda (x) (setq i x)) into setters
  collect (lambda () i) into getters
  finally
  (print (funcall (elt getters 0)))
  (funcall (elt setters 4) 42)
  (print (funcall (elt getters 9
=> 10
=> 42
If this difference matters to you, just be more explicit.
Pascal
--
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp-likeness

[Pascal Bourguignon]

[EMAIL PROTECTED] (Peter Lewerin) writes:

> Fred Gilham <[EMAIL PROTECTED]> wrote 
> 
> > > And Lisp's "macro language" isn't involved at all here.
> 
> > Also, #' is a read-macro.
> 
> A read-macro and a macro aren't the same thing.
> 
> > Then there's the "defun" macro . . . .
> 
> There is IMHO a difference between using a macro and using the
> "macro language".

What macro language?  Common-Lisp?

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
-- 
http://mail.python.org/mailman/listinfo/python-list

Code with random module faster on the vm than the vm host...

[Pascal Bit]

Here's the code:

from random import random
from time import clock

s = clock()

for i in (1, 2, 3, 6, 8):
M = 0
N = 10**i

for n in xrange(N):
r = random()
if 0.5 < r < 0.6:
M += 1

k = (N, float(M)/N)

print (clock()-s)

Running on win7 python 2.7 32 bit it uses around 30 seconds avg.
Running on xubuntu, 32 bit, on vmware on windows 7: 20 seconds!
The code runs faster on vm, than the computer itself...
The python version in this case is 1.5 times faster...
I don't understand.

What causes this?
--
https://mail.python.org/mailman/listinfo/python-list

Re: Xah's Edu Corner: Responsible Software Licensing

[Pascal Bourguignon]

"Xah Lee" <[EMAIL PROTECTED]> writes:
> As i've indicated in the Responsible Licensing article, that today's
> software come with disclaimers that essentially say the producer is not
> liable even if the software don't work at all. It will be hard to
> change this zero responsibility stance to a 100% responsibility stance.
> However, we can start in small ways. Suppose, if you write a piece of
> email program, although there are a myriad scenarios that it will have
> problems sending email and in reality such problem happens often, but a
> responsible software programer can at least GUARANTEE, that the
> software WILL work to some extent of its described utility. In the
> email program example, a responsible author can say “We GUARANTEE
> that this software will send out emails in a normal setting. If not, we
> will refund the money you have paid, or, send you $1 USD.” Although
> this may seem fuzzy and silly, but it is a start. By giving a very safe
> minimal guarantee of functionality, possibly with a nominal liability
> assurance, the author will have made a _Responsible License_.

You have a problem of definition of the meaning of "normal setting".  

This problem is easily resolved with the source of the program: the
source of the program IS the CONTRACT.  If you respect the language
(the semantics, or underlying virtual machine expected by the
program), and if you respect the pre-conditions embedded in the
program, then you get the guarantee plainly written in the program as
post-conditions.  You cannot get it more explicitely than from the
sources of the program (and the specifications of its programming
language).

So wanting more than the mere sources, you are wanting to reject
programming language not formally specified, and programs provided
without the sources.  We can do better on the programming language
formal specifications side, but on the program sources side, I don't
know what we can do more than GPL or BSD...


Actually, the whole point is to let the _user_ of the program to take
_responsibility_ for the program he uses,  and not to cowardly 
discharge his (the user's) responsability to somebody else.


When you compute the tip to add to your invoice at the restaurant, you
don't ask the inventor of the multiplication algorithm or your
teachers to take any responsibility for your wrong or right
application of the operation.  Let the users be responsible!


-- 
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Xah's Edu Corner: Tech Geekers and their Style

[Pascal Bourguignon]

"Xah Lee" <[EMAIL PROTECTED]> writes:

> Sometimes you want your text to flow into multiple columns, as in
> newspaper's layout. However, as of 2005-12 this is not yet possible.
> One can make-do by hard-coding it into HTML TABLE using multiple
> columns. It is a pain because when you change your text, you have to
> manually cut and paste to justify each and every columns by
> trial-n-error.
>
> A proposed solution is in CSS3 “Multi-column layout”, drafted in
> 2001 but not yet in any mainstream browsers as of 2005-12. See
> http://www.w3.org/TR/2001/WD-css3-multicol-20010118/
>
> With all the whizbang of styles and features in CSS2, a basic,
> necessary, functional layout feature as multi-columns is not there yet.
> This is a indication of the fatuousness of the IT industry's
> technologies and its people.

In general, the IT industry doesn't address the needs of the Neandertals.

If you want a narrow column, you just reduce the size of your window!



-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"You question the worthiness of my code? I should kill you where you
stand!"
-- 
http://mail.python.org/mailman/listinfo/python-list

newbie question about import tools

[pascal . roca]

i have just downloas python and trying to import tools module

C:\Documents and Settings\toto>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v
Type "help", "copyright", "credits" or "license"
>>> import tools
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tools
>>> import os
>>> print os

>>> import code
>>> print code

>>>

do i need to download tools.pyc ?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Nature of the “Unix Philosophy”

[Pascal Bourguignon]

Frank Silvermann <[EMAIL PROTECTED]> writes:

> Nils O. Selåsdal wrote:
>> Xah Lee wrote:
>>> The Nature of the “Unix Philosophy”
> [snip]
>
>> Perhaps you should take a peek at the ideas in Plan 9 from Bell Labs,
>> which is  a continuation of this philosophy, unlike the "modern" unix
>> clones.
> Is there an actual Plan 9?  I'm only aware of the one from Outer
> Space. frank

No, there is no _actual_ Plan 9.  The OS named "Plan 9" is named after
the Outer Space one.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.99% empty space.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Torben Ægidius Mogensen wrote:

> On a similar note, is a statically typed langauge more or less
> expressive than a dynamically typed language?  Some would say less, as
> you can write programs in a dynamically typed language that you can't
> compile in a statically typed language (without a lot of encoding),
> whereas the converse isn't true.

It's important to get the levels right here: A programming language with 
a rich static type system is more expressive at the type level, but less 
expressive at the base level (for some useful notion of expressiveness ;).

> However, I think this is misleading,
> as it ignores the feedback issue: It takes longer for the average
> programmer to get the program working in the dynamically typed
> language.

This doesn't seem to capture what I hear from Haskell programmers who 
say that it typically takes quite a while to convince the Haskell 
compiler to accept their programs. (They perceive this to be worthwhile 
because of some benefits wrt correctness they claim to get in return.)


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

Joachim Durchholz <[EMAIL PROTECTED]> writes:
> Raffael Cavallaro schrieb:
>> a program which would be perfectly permissible in a dynamically
>> typed language such as common lisp - for example - heterogeneous
>> lists and forward references to as yet non-existent functions.
>
> Um... heterogenous lists are not necessarily a sign of
> expressiveness. The vast majority of cases can be transformed to
> homogenous lists (though these might then contain closures or OO
> objects).

In lisp, all lists are homogenous: lists of T.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Neelakantan Krishnaswami wrote:
> In article <[EMAIL PROTECTED]>, Pascal Costanza wrote:
>> Torben Ægidius Mogensen wrote:
>>
>>> On a similar note, is a statically typed langauge more or less
>>> expressive than a dynamically typed language?  Some would say less, as
>>> you can write programs in a dynamically typed language that you can't
>>> compile in a statically typed language (without a lot of encoding),
>>> whereas the converse isn't true.
>> It's important to get the levels right here: A programming language
>> with a rich static type system is more expressive at the type level,
>> but less expressive at the base level (for some useful notion of
>> expressiveness ;).
> 
> This doesn't seem obviously the case to me. If you have static
> information about your program, the compiler can use this information
> to automate a lot of grunt work away.
> 
> Haskell's system of typeclasses work this way. If you tell the
> compiler how to print integers, and how to print lists, then when you
> call a print function on a list of list of integers, then the compiler
> will automatically figure out the right print function using your base
> definitions. This yields an increase in Felleisen-expressiveness over
> a dynamically typed language, because you would need to globally
> restructure your program to achieve a similar effect.
> 
> More dramatic are the "polytypic" programming languages, which let you
> automate even more by letting you write generic map, fold, and print
> functions which work at every type.

Yes, but these decisions are taken at compile time, without running the 
program.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Torben Ægidius Mogensen wrote:
> Raffael Cavallaro <[EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com> writes:
> 
>> On 2006-06-14 16:36:52 -0400, Pascal Bourguignon <[EMAIL PROTECTED]> said:
>>
>>> In lisp, all lists are homogenous: lists of T.
>> CL-USER 123 > (loop for elt in (list #\c 1 2.0d0 (/ 2 3)) collect
>> (type-of elt))
>> (CHARACTER FIXNUM DOUBLE-FLOAT RATIO)
>>
>> i.e., "heterogenous" in the common lisp sense: having different
>> dynamic types, not in the H-M sense in which all lisp values are of
>> the single union type T.
> 
> What's the difference?  Dynamically types values _are_ all members of
> a single tagged union type.

Yes, but that's mostly a meaningless statement in a dynamically typed 
language. In a dynamically typed language, you typically don't care 
about the static types.

> The main difference is that the tages
> aren't always visible and that there are only a fixed, predefined
> number of them.

Depending on the language, the number of "tags" is not fixed.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Torben Ægidius Mogensen wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> Torben Ægidius Mogensen wrote:
>>
>>> On a similar note, is a statically typed langauge more or less
>>> expressive than a dynamically typed language?  Some would say less, as
>>> you can write programs in a dynamically typed language that you can't
>>> compile in a statically typed language (without a lot of encoding),
>>> whereas the converse isn't true.
>> It's important to get the levels right here: A programming language
>> with a rich static type system is more expressive at the type level,
>> but less expressive at the base level (for some useful notion of
>> expressiveness ;).
>>
>>> However, I think this is misleading,
>>> as it ignores the feedback issue: It takes longer for the average
>>> programmer to get the program working in the dynamically typed
>>> language.
>> This doesn't seem to capture what I hear from Haskell programmers who
>> say that it typically takes quite a while to convince the Haskell
>> compiler to accept their programs. (They perceive this to be
>> worthwhile because of some benefits wrt correctness they claim to get
>> in return.)
> 
> That's the point: Bugs that in dynamically typed languages would
> require testing to find are found by the compiler in a statically
> typed language.

Yes. However, unfortunately statically typed languages also reject 
programs that don't have such bugs. It's a tradeoff whether you want to 
spend time to deal with them or not.

> So whil eit may take onger to get a program thatgets
> past the compiler, it takes less time to get a program that works.

That's incorrect. See http://haskell.org/papers/NSWC/jfp.ps - especially 
Figure 3.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Torben Ægidius Mogensen wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> Torben Ægidius Mogensen wrote:
> 
>>> So while it may take longer to get a program that gets
>>> past the compiler, it takes less time to get a program that works.
>> That's incorrect. See http://haskell.org/papers/NSWC/jfp.ps -
>> especially Figure 3.
> 
> There are many other differences between these languages than static
> vs. dynamic types, and some of these differences are likely to be more
> significant.  What you need to test is langauges with similar features
> and syntax, except one is statically typed and the other dynamically
> typed.
> 
> And since these languages would be quite similar, you can use the same
> test persons: First let one half solve a problem in the statically
> typed language and the other half the same problem in the dynamically
> typed language, then swap for the next problem.  If you let a dozen
> persons each solve half a dozen problems, half in the statically typed
> language and half in the dynamically typed language (using different
> splits for each problem), you might get a useful figure.

...and until then claims about the influence of static type systems on 
the speed with which you can implement working programs are purely 
guesswork. That's the only point I need to make to show that your 
original unqualified statement, namely that it takes less time to get a 
program that works, is incorrect.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

one.  This is simply 
> not so.  If types DON'T mean a compile-time method for proving the 
> absence of certain program behaviors, then they don't mean anything at 
> all.  Pretending that there's a distinction at runtime between "type 
> errors" and "other errors" serves only to confuse things and 
> artificially limit which problems we are willing to concieve as being 
> solvable by types.

Your problem doesn't exist. Just say "types" when you're amongst your 
own folks, and "static types" when you're amongst a broader audience, 
and everything's fine. Instead of focusing on terminology, just focus on 
the contents.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Matthias Blume wrote:
> "Rob Thorpe" <[EMAIL PROTECTED]> writes:
> 
>> I don't think dynamic typing is that nebulous.  I remember this being
>> discussed elsewhere some time ago, I'll post the same reply I did then
>> ..
>>
>>
>> A language is statically typed if a variable has a property - called
>> it's type - attached to it, and given it's type it can only represent
>> values defined by a certain class.
> 
> By this definition, all languages are statically typed (by making that
> "certain class" the set of all values).  Moreover, this "definition",
> when read the way you probably wanted it to be read, requires some
> considerable stretch to accommodate existing static type systems such
> as F_\omega.
> 
> 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.

How does your definition exclude the trivial type system in which the 
only typing judgment states that every expression is acceptable?


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> wrote:
>> Types can be represented at runtime via type tags. You could insist on 
>> using the term "dynamically tagged languages", but this wouldn't change 
>> a lot. Exactly _because_ it doesn't make sense in a statically typed 
>> setting, the term "dynamically typed language" is good enough to 
>> communicate what we are talking about - i.e. not (static) typing.
> 
> Okay, fair enough.  It's certainly possible to use the same sequence of 
> letters to mean two different things in different contexts.  The problem 
> arises, then, when Torben writes:
> 
> : That's not really the difference between static and dynamic typing.
> : Static typing means that there exist a typing at compile-time that
> : guarantess against run-time type violations.  Dynamic typing means
> : that such violations are detected at run-time.
> 
> This is clearly not using the word "type" to mean two different things 
> in different contexts.  Rather, it is speaking under the mistaken 
> impression that "static typing" and "dynamic typing" are varieties of 
> some general thing called "typing."  In fact, the phrase "dynamically 
> typed" was invented to do precisely that.  My argument is not really 
> with LISP programmers talking about types, by which they would mean 
> approximately the same thing Java programmers mean by "class."  My point 
> here concerns the confusion that results from the conception that there 
> is this binary distinction (or continuum, or any other simple 
> relationship) between a "statically typed" and a "dynamically typed" 
> language.

There is an overlap in the sense that some static type systems cover 
only types as sets of values whose correct use could as well be checked 
dynamically.

Yes, it's correct that more advanced static type systems can provide 
more semantics than that (and vice versa).


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:

> The conversation I would *really* like to have is the one where we
> discuss what all the differences are, functionally, between the two,
> and what the implications of those differences are, without trying
> to address which approach is "right" or "better", because those are
> dependent on the problem domain anyway, and because I can
> make up my own mind just fine about which one I prefer.

My current take on this is that static typing and dynamic typing are 
incompatible, at least in their "extreme" variants.

The simplest examples I have found are this:

- In a statically typed language, you can have variables that contain 
only first-class functions at runtime that are guaranteed to have a 
specific return type. Other values are rejected, and the rejection 
happens at compile time.

In dynamically typed languages, this is impossible because you can never 
be sure about the types of return values - you cannot predict the 
future. This can at best be approximated.


- In a dynamically typed language, you can run programs successfully 
that are not acceptable by static type systems. Here is an example in 
Common Lisp:

; A class "person" with no superclasses and with the only field "name":
(defclass person ()
   (name))

; A test program:
(defun test ()
   (let ((p (make-instance 'person)))
 (eval (read))
 (slot-value p 'address)))

(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.

(Even without the call to (eval (read)), in Common Lisp the call to 
(slot-value p 'address) would raise an exception which gives the user a 
chance to fix things and continue from the point in the control flow 
where the exception was raised.)

I cannot imagine a static type system which has a chance to predict that 
this program can successfully run without essentially accepting all 
kinds of programs.

At least, development environments for languages like Smalltalk, Common 
Lisp, Java, etc., make use of such program updates to improve 
edit-compile-test cycles. However, it is also possible (and done in 
practice) to use such program updates to minimize downtimes when adding 
new features to deployed systems.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> - In a dynamically typed language, you can run programs successfully
>>   that are not acceptable by static type systems.
> 
> This statement is false.

The example I have given is more important than this statement.

> For every program that can run successfully to completion there exists
> a static type system which accepts that program.  Moreover, there is
> at least one static type system that accepts all such programs.
> 
> What you mean is that for static type systems that are restrictive
> enough to be useful in practice there always exist programs which
> (after type erasure in an untyped setting, i.e., by switching to a
> different language) would run to completion, but which are rejected by
> the static type system.

No, that's not what I mean.

>> Here is an example in Common Lisp:
>>
>> ; A class "person" with no superclasses and with the only field "name":
>> (defclass person ()
>>(name))
>>
>> ; A test program:
>> (defun test ()
>>(let ((p (make-instance 'person)))
>>  (eval (read))
>>  (slot-value p 'address)))
>>
>> (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


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Rob Thorpe wrote:
> Pascal Costanza wrote:
>> Matthias Blume wrote:
>>> Pascal Costanza <[EMAIL PROTECTED]> 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/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Pascal Costanza wrote:
>> Rob Thorpe wrote:
>>> Pascal Costanza wrote:
>>>> Matthias Blume wrote:
>>>>> Pascal Costanza <[EMAIL PROTECTED]> 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.
> 
> It's not difficult in principle:
> 
>  - for each class [*], define a function which converts an 'old' value of
>that class to a 'new' value (the ability to do this is necessary anyway
>to support some kinds of upgrade). A default conversion function may be
>autogenerated if the class definition has changed only in minor ways.

Yep, this is more or less exactly how CLOS does it. (The conversion 
function is called update-instance-for-redefined-class, and you can 
provide your own methods on it.)

>  - typecheck the new program and the conversion functions, using the old
>type definitions for the argument of each conversion function, and the
>new type definitions for its result.

The problem here is: The program is already executing, so this typecheck 
isn't performed at compile-time, in the strict sense of the word (i.e., 
before the program is deployed). It may still be a syntactic analysis, 
but you don't get the kind of guarantees anymore that you typically 
expect from a static type checker _before_ the program is started in the 
first place.

(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.)

>  - have the debugger apply the conversions to all values, and then resume
>the program.

In CLOS, this conversion is defined as part of the language proper, but 
this is mostly because Common Lisp doesn't make a sharp distinction 
between debugging capabilities and "regular" language features. (I think 
it's a good thing that there is no strong barrier against having 
debugging capabilities in a deployed program.)


> [*] or nearest equivalent in a non-OO language.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

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/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Marshall wrote:
>> Chris Smith wrote:
>>> Marshall <[EMAIL PROTECTED]> wrote:
>>>
>>>> I think what this highlights is the fact that our existing terminology
>>>> is not up to the task of representing all the possible design
>>>> choices we could make. Some parts of dynamic vs. static
>>>> a mutually exclusive; some parts are orthogonal.
>>> Really?  I can see that in a strong enough static type system, many
>>> dynamic typing features would become unobservable and therefore would be
>>> pragmatically excluded from any probable implementations... but I don't
>>> see any other kind of mutual exclusion between the two.
>> Well, it strikes me that some of what the dynamic camp likes
>> is the actual *absence* of declared types, or the necessity
>> of having them.
> 
> So why aren't they happy with something like, say, Alice ML, which is
> statically typed, but has a "dynamic" type and type inference? I mean
> this as a serious question.

Note: I haven't yet worked with such a language, but here is my take anyway.

A statically type language requires you to think about two models of 
your program at the same time: the static type model and the dynamic 
behavioral model. A static type system ensures that these two 
_different_ (that's important!) perspectives are always in sync. This is 
especially valuable in settings where you know your domain well and want 
to rely on feedback by your compiler that you haven't made any mistakes 
in encoding your knowledge. (A static type system based on type 
inferencing doesn't essentially change the requirement to think in two 
models at the same time.)

A dynamically typed language is especially well suited when you don't 
(yet) have a good idea about your domain and you want to use programming 
especially to explore that domain. Some static typing advocates claim 
that static typing is still suitable for exploring domains because of 
the compiler's feedback about the preliminary encoding of your 
incomplete knowledge, but the disadvantages are a) that you still have 
to think about two models at the same time when you don't even have 
_one_ model ready and b) that you cannot just run your incomplete 
program to see what it does as part of your exploration.

A statically typed language with a dynamic type treats dynamic typing as 
the exception, not as the general approach, so this doesn't help a lot 
in the second setting (or so it seems to me).

A language like Common Lisp treats static typing as the exception, so 
you can write a program without static types / type checks, but later on 
add type declarations as soon as you get a better understanding of your 
domain. Common Lisp implementations like CMUCL or SBCL even include 
static type inference to aid you here, which gives you warnings but 
still allows you to run a program even in the presence of static type 
errors. I guess the feedback you get from such a system is probably not 
"strong" enough to be appreciated by static typing advocates in the 
first setting (where you have a good understanding of your domain).


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

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.

>> In the terminology I'm suggesting, the object has no type in this language
>> (assuming we're talking about a Smalltalk-like language without any type 
>> system
>> extensions).
> 
> I suspect you'll see the Smalltalk version of the objections raised in 
> response to my post earlier.  In other words, whatever terminology you 
> think is consistent, you'll probably have a tough time convincing 
> Smalltalkers to stop saying "type" if they did before.  If you exclude 
> "message not understood" as a type error, then I think you're excluding 
> type errors from Smalltalk entirely, which contradicts the psychological 
> understanding again.

Sending a message to an object that does not understand that message is 
a type error. The "message not understood" machinery can be seen either 
as a way to escape from this type error in case it occurs and allow the 
program to still do something useful, or to actually remove (some) 
potential type errors. Which view you take probably depends on what your 
concrete implementation of "message not understood" does. For example, 
if it simply forwards the message to another object that is known to be 
able to respond to it, then you remove a potential type error; however, 
if it pops up a dialog box to ask the user how to continue from here, it 
is still a type error, but just gives you a way to deal with it at runtime.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

[EMAIL PROTECTED] wrote:
>  > A statically type language requires you to think about two models of
> 
>> your program at the same time: the static type model and the dynamic
>> behavioral model. A static type system ensures that these two
>> _different_ (that's important!) perspectives are always in sync.
> 
> I have trouble understanding your use of the wording "Model of a
> program".
> If it is a system that behaves according to the rules of your program
> then
> statements about your program should consider *all* possible models.
> If it is a formal system that makes statements about properties of your
> program
> than the static type system is a simplified model that is suitable for
> automatic
> analysis and your runtime model is in most cases nonexistent.
> Can you give a definition of a "model of a program"? Can you explain
> why
> Lisp doesn't have two (SBCL does do a lot of typechecking and gives
> type errors)?

I wasn't talking about models that the language implementation may or 
may not have, but the models that I as a programmer must have in order 
to convince the compiler to let me program run.

Consider a simple expression like 'a + b': In a dynamically typed 
language, all I need to have in mind is that the program will attempt to 
add two numbers. In a statically typed language, I additionally need to 
know that there must a guarantee that a and b will always hold numbers.

In a trivial example like this, this doesn't hurt a lot, but can be 
problematic as soon as the program size grows.

>> This is
>> especially valuable in settings where you know your domain well and want
>> to rely on feedback by your compiler that you haven't made any mistakes
>> in encoding your knowledge. (A static type system based on type
>> inferencing doesn't essentially change the requirement to think in two
>> models at the same time.)
> 
> It is also valuable when you don't know your domain very well and you
> want to rely on feedback by your compiler that you haven't made any
> mistakes  in encoding your limited knowledge

I have more or less used exactly the same words in the paragraph that 
followed the one you cited from my previous posting, and I have already 
given a reply there.

>> A dynamically typed language is especially well suited when you don't
>> (yet) have a good idea about your domain and you want to use programming
>> especially to explore that domain. our domain).
> 
> In the sense that you can start writing code without the compiler
> pointing out
> all but the most glaring holes in your program, I agree.

I don't know what language environments you are used to, but the Common 
Lisp compilers I use always point out the most glaring holes in my 
programs. But maybe I just have trouble understanding your use of the 
wording "most glaring holes". Can you give a definition of "most glaring 
holes"? ;)

> Most of your
> arguments
> aren't very convincing and the thruth is that I have seem lisp
> programmers using
> the debugger to find out that you can't add a number and a hastable.
> The static view
> was not there and the dynamic view must have been too complicated so
> they had
> nothing to think about.

We have all seen less-than-average programmers who would fail in all 
kinds of languages. What they do is typically not very illuminating.

My goal is not to convince anyone, my goal is to illustrate for those 
who are interested in getting a possibly different perspective.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Andreas Rossberg wrote:
> Pascal Costanza wrote:
>>
>> Consider a simple expression like 'a + b': In a dynamically typed 
>> language, all I need to have in mind is that the program will attempt 
>> to add two numbers. In a statically typed language, I additionally 
>> need to know that there must a guarantee that a and b will always hold 
>> numbers.
> 
> I'm confused. Are you telling that you just write a+b in your programs 
> without trying to ensure that a and b are in fact numbers??

Basically, yes.

Note that this is a simplistic example. Consider, instead, sending a 
message to an object, or calling a generic function, without ensuring 
that there will be applicable methods for all possible cases. When I get 
a "message not understood" exception, I can then decide whether that 
kind of object shouldn't be a receiver in the first place, or else 
whether I should define an appropriate method. I don't want to be forced 
to decide this upfront, because either I don't want to be bothered, or 
maybe I simply can't because I don't understand the domain well enough 
yet, or maybe I want to keep a hook to be able to update the program 
appropriately while it is running.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

Andreas Rossberg <[EMAIL PROTECTED]> writes:

> Pascal Costanza wrote:
>> Consider a simple expression like 'a + b': In a dynamically typed
>> language, all I need to have in mind is that the program will
>> attempt to add two numbers. In a statically typed language, I
>> additionally need to know that there must a guarantee that a and b
>> will always hold numbers.
>
> I'm confused. Are you telling that you just write a+b in your programs
> without trying to ensure that a and b are in fact numbers??

Of course.

(shadow '(+ *))
(defun + (&rest args) `(+ ,@args))
(defun * (&rest args) `(* ,@args))

(let ((var 'x) (init 'b) (slop 'a))
   (+ init (* slop var))) 
--> (+ B (* A X))


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

Pascal Costanza <[EMAIL PROTECTED]> writes:

> Andreas Rossberg wrote:
>> Pascal Costanza wrote:
>>>
>>> Consider a simple expression like 'a + b': In a dynamically typed
>>> language, all I need to have in mind is that the program will
>>> attempt to add two numbers. In a statically typed language, I
>>> additionally need to know that there must a guarantee that a and b
>>> will always hold numbers.
>> I'm confused. Are you telling that you just write a+b in your
>> programs without trying to ensure that a and b are in fact numbers??
>
> Basically, yes.
>
> Note that this is a simplistic example. Consider, instead, sending a
> message to an object, or calling a generic function, without ensuring
> that there will be applicable methods for all possible cases. When I
> get a "message not understood" exception, I can then decide whether
> that kind of object shouldn't be a receiver in the first place, or
> else whether I should define an appropriate method. I don't want to be
> forced to decide this upfront, because either I don't want to be
> bothered, or maybe I simply can't because I don't understand the
> domain well enough yet, or maybe I want to keep a hook to be able to
> update the program appropriately while it is running.

Moreover, a good proportion of the program and a good number of
algorithms don't even need to know the type of the objects they
manipulate.

For example, sort doesn't need to know what type the objects it sorts
are.  It only needs to be given a function that is able to compare the
objects.

Only a few "primitive" functions need specific types.

So basically, you've got a big black box of applicaition code in the
middle that doesn't care what type of value they get, and you've got a
few input values of a specific type, a few processing functions
needing a specific type and returning a specific type, and a few
output values that are expected to be of a specific type.  At anytime,
you may change the type of the input values, and ensure that the
needed processing functions will be able to handle this new input
type, and the output gets mapped to the expected type.


Why should adding a few functions or methods, and providing input
values of a new type be rejected from a statically checked  point of
view by a compiled program that would be mostly bit-for-bit the same
with or without this new type?

Of course, in the process of so modifying the program, we may get some
dynamically detected type errors that we would correct as Pascal
indicated.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"Specifications are for the weak and timid!"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

Matthias Blume <[EMAIL PROTECTED]> writes:

> Pascal Bourguignon <[EMAIL PROTECTED]> writes:
>
>> Moreover, a good proportion of the program and a good number of
>> algorithms don't even need to know the type of the objects they
>> manipulate.
>>
>> For example, sort doesn't need to know what type the objects it sorts
>> are.  It only needs to be given a function that is able to compare the
>> objects.
>
> Of course, some statically typed languages handle this sort of thing
> routinely.
>
>> Only a few "primitive" functions need specific types.
>
> Your sort function from above also has a specific type -- a type which
> represents the fact that the objects to be sorted must be acceptable
> input to the comparison function.

Well, not exactly.  sort is a higher level function. The type of its
arguments is an implicit parameter of the sort function.

 (sort "Hello World"  (function char<=))
 --> " HWdellloor"

 (sort '(52 12 42 37) (function <=))
 --> (12 37 42 52)

 (sort (list (make-instance 'person   :name "Pascal")
 (make-instance 'unit :name "Pascal")
 (make-instance 'programming-language :name "Pascal"))
   (lambda (a b) (string<= (class-name (class-of a))
   (class-name (class-of b)
 --> (#
  #
  #)


In Common Lisp, sort is specified to take a parameter of type SEQUENCE
= (or vector list), and if a list it should be a proper list,
and a function taking two arguments (of any type) 
and returning a generalized boolean (that is anything can be returned,
NIL is false, something else is true)


So you could say that:

   (sort (sequence element-type)
 (function (element-type element-type) boolean))
--> (sequence element-type)

but element-type is not a direct parameter of sort, and can change for
all calls event at the same call point:

(mapcar (lambda (s) (sort s (lambda (a b) (<= (sxhash a) (sxhash b)
(list (vector 52 12 42 37)
  (list   52 12 42 37)
  (list "abc" 'def (make-instance 'person :name "Zorro") 76)))
--> (#(12 37 42 52)
  (12 37 42 52)
  (76 # DEF "abc"))


>> So basically, you've got a big black box of applicaition code in the
>> middle that doesn't care what type of value they get, and you've got a
>> few input values of a specific type, a few processing functions
>> needing a specific type and returning a specific type, and a few
>> output values that are expected to be of a specific type.  At anytime,
>> you may change the type of the input values, and ensure that the
>> needed processing functions will be able to handle this new input
>> type, and the output gets mapped to the expected type.
>
> ...or you type-check your "black box" and make sure that no matter how
> you will ever change the type of the inputs (in accordance with the
> interface type of the box) you get a valid program.

When?  At run-time?  All the modifications I spoke of can be done at
run-time in Lisp.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

"Marshall" <[EMAIL PROTECTED]> writes:

> Pascal Costanza wrote:
>>
>> Consider a simple expression like 'a + b': In a dynamically typed
>> language, all I need to have in mind is that the program will attempt to
>> add two numbers. In a statically typed language, I additionally need to
>> know that there must a guarantee that a and b will always hold numbers.
>
> I still don't really see the difference.
>
> I would not expect that the dynamic programmer will be
> thinking that this code will have two numbers most of the
> time but sometimes not, and fail. I would expect that in both
> static and dynamic, the thought is that that code is adding
> two numbers, with the difference being the static context
> gives one a proof that this is so. In this simple example,
> the static case is better, but this is not free, and the cost
> of the static case is evident elsewhere, but maybe not
> illuminated by this example.
>
> This thread's exploration of the mindset of the two kinds
> of programmers is difficult. It is actually quite difficult,
> (possibly impossible) to reconstruct mental states
> though introspection. Nonetheless I don't see any
> other way to proceed. Pair programming?

Well this is a question of data flow.  As I explained, there's a whole
body of functions that don't process concretely the data they get.
But of course, eventually you must write a function that do some
concrete processing on the data it gets.  That's when you consider the
type of the values. Such functions may be generic functions with
methods dispatching on the actual type of the parameters, or you may
encounter some TYPECASE or COND inside the function before calling
non-abstract "primitives" that work only on some specific type.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"I have challenged the entire quality assurance team to a Bat-Leth
contest.  They will not concern us again."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

Matthias Blume <[EMAIL PROTECTED]> writes:

> Pascal Bourguignon <[EMAIL PROTECTED]> writes:
>
>> Matthias Blume <[EMAIL PROTECTED]> writes:
>>
>>> Pascal Bourguignon <[EMAIL PROTECTED]> writes:
>>>
>>>> Moreover, a good proportion of the program and a good number of
>>>> algorithms don't even need to know the type of the objects they
>>>> manipulate.
>>>>
>>>> For example, sort doesn't need to know what type the objects it sorts
>>>> are.  It only needs to be given a function that is able to compare the
>>>> objects.
>>>
>>> Of course, some statically typed languages handle this sort of thing
>>> routinely.
>>>
>>>> Only a few "primitive" functions need specific types.
>>>
>>> Your sort function from above also has a specific type -- a type which
>>> represents the fact that the objects to be sorted must be acceptable
>>> input to the comparison function.
>>
>> Well, not exactly.
>
> What do you mean by "not exactly".
>
>>  sort is a higher level function. The type of its
>> arguments is an implicit parameter of the sort function.
>
> What do you mean by "higher-level"? Maybe you meant "higher-order" or
> "polymorphic"?

Yes, that's what I wanted to say.

> [ rest snipped ]
>
> You might want to look up "System F".
> [...]
>>> ...or you type-check your "black box" and make sure that no matter how
>>> you will ever change the type of the inputs (in accordance with the
>>> interface type of the box) you get a valid program.
>>
>> When?
>
> When what?

When will you type-check the "black box"?

A function such as:

(defun f (x y)
   (if (g x)
  (h x y)
  (i y x)))

in the context of a given program could be type-infered statically as
taking an integer and a string as argument.  If the compiler did this
inference, it could perhaps generate code specific to these types.

But it's always possible at run-time that new functions and new
function calls be generated such as:

(let ((x "two"))
  (eval `(defmethod g ((self ,(type-of x))) t))
  (eval `(defmethod h ((x ,(type-of x)) (y string)) 
   (,(intern (format nil "DO-SOMETHING-WITH-A-~A" (type-of x))) x) 
   (do-something-with-a-string y)))
  (funcall (compile nil `(let ((x ,x)) (lambda () (f x "Hi!"))

Will you execute the whole type-inference on the whole program "black
box" everytime you define a new function?  Will you recompile all the
"black box" functions to take into account the new type the arguments
can be now?

This wouldn't be too efficient.  Let's just say that by default, all
arguments and variable are of type T, so the type checking is trivial,
and the generated code is, by default, totally generic.


Only the few concrete, low-level functions need to know the types of
their arguments and variables.  In these functions, either the lisp
compiler will do the type inference (starting from the predefined
primitives), or the programmer will declare the types to inform the
compiler what to expect.

(defun do-something-with-a-string (x)
  (declare (string x))
  ...)

(defun do-something-with-a-integer (x)
  (declare (integer x))
  ...)

...

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> 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.
> 
> Yes, the phrase "runtime type error" is actually a misnomer.  What one
> usually means by that is a situation where the operational semantics
> is "stuck", i.e., where the program, while not yet arrived at what's
> considered a "result", cannot make any progress because the current
> configuration does not match any of the rules of the dynamic
> semantics.
> 
> The reason why we call this a "type error" is that such situations are
> precisely the ones we want to statically rule out using sound static
> type systems.  So it is a "type error" in the sense that the static
> semantics was not strong enough to rule it out.
> 
>> Sending a message to an object that does not understand that message
>> is a type error. The "message not understood" machinery can be seen
>> either as a way to escape from this type error in case it occurs and
>> allow the program to still do something useful, or to actually remove
>> (some) potential type errors.
> 
> I disagree with this.  If the program keeps running in a defined way,
> then it is not what I would call a type error.  It definitely is not
> an error in the sense I described above.

If your view of a running program is that it is a "closed" system, then 
you're right. However, maybe there are several layers involved, so what 
appears to be a well-defined behavior from the outside may still be 
regarded as a type error internally.

A very obvious example of this is when you run a program in a debugger. 
There are two levels involved here: the program signals a type error, 
but that doesn't mean that the system as a whole is stuck. Instead, the 
debugger takes over and offers ways to deal with the type error. The 
very same program run without debugging support would indeed simply be 
stuck in the same situation.

So to rephrase: It depends on whether you use the "message not 
understood" machinery as a way to provide well-defined behavior for the 
base level, or rather as a means to deal with an otherwise unanticipated 
situation. In the former case it extends the language to remove certain 
type errors, in the latter case it provides a kind of debugging facility 
(and it indeed may be a good idea to deploy programs with debugging 
facilities, and not only use debugging tools at development time).

This is actually related to the notion of reflection, as coined by Brian 
C. Smith. In a reflective architecture, you distinguish between various 
interpreters, each of which interprets the program at the next level. A 
debugger is a program that runs at a different level than a base program 
that it debugs. However, the reflective system as a whole is "just" a 
single program seen from the outside (with one interpreter that runs the 
whole reflective tower). This distinction between the internal and the 
external view of a reflective system was already made by Brian Smith.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> wrote:
>> 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.
> 
> Hmm.  I'm afraid I'm going to be picky here.  I think you need to 
> clarify what is meant by "appropriate".

No, I cannot be a lot clearer here. What operations are appropriate for 
what values largely depends on the intentions of a programmer. Adding a 
number to a string is inappropriate, no matter how a program behaves 
when this actually occurs (whether it continues to execute the operation 
blindly, throws a continuable exception, or just gets stuck).

> If you mean "the operation will 
> not complete successfully" as I suspect you do, then we're closer...

No, we're not. You're giving a purely technical definition here, that 
may or may not relate to the programmer's (or "designer's") 
understanding of the domain.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:

> I am sceptical of the idea that when programming in a dynamically
> typed language one doesn't have to think about both models as well.
> I don't have a good model of the mental process of working
> in a dynamically typed language, but how could that be the case?
> (I'm not asking rhetorically.) Do you then run your program over
> and over, mechanically correcting the code each time you discover
> a type error? In other words, if you're not thinking of the type model,
> are you using the runtime behavior of the program as an assistant,
> the way I use the static analysis of the program as an assistant?

Yes.

> I don't accept the idea about pairing the appropriateness of each
> system according to whether one is doing exploratory programming.
> I do exploratory programming all the time, and I use the static type
> system as an aide in doing so. Rather I think this is just another
> manifestation of the differences in the mental processes between
> static typed programmers and dynamic type programmers, which
> we are beginning to glimpse but which is still mostly unknown.

Probably.

> Oh, and I also want to say that of all the cross-posted mega threads
> on static vs. dynamic typing, this is the best one ever. Most info;
> least flames. Yay us!

Yay! :)


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:
> Pascal Costanza wrote:
>> Consider a simple expression like 'a + b': In a dynamically typed
>> language, all I need to have in mind is that the program will attempt to
>> add two numbers. In a statically typed language, I additionally need to
>> know that there must a guarantee that a and b will always hold numbers.
> 
> I still don't really see the difference.
> 
> I would not expect that the dynamic programmer will be
> thinking that this code will have two numbers most of the
> time but sometimes not, and fail. I would expect that in both
> static and dynamic, the thought is that that code is adding
> two numbers, with the difference being the static context
> gives one a proof that this is so.

There is a third option: it may be that at the point where I am writing 
this code, I simply don't bother yet whether a and b will always be 
numbers. In case something other than numbers pop up, I can then make a 
decision how to proceed from there.

> In this simple example,
> the static case is better, but this is not free, and the cost
> of the static case is evident elsewhere, but maybe not
> illuminated by this example.

Yes, maybe the example is not the best one. This kind of example, 
however, occurs quite often when programming in an object-oriented 
style, where you don't know yet what objects will and will not respond 
to a message / generic function. Even in the example above, it could be 
that you can give an appropriate definition for + for objects other than 
numbers.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:
> 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.

Nowadays, we have more options wrt what it means to "ship" code. It 
could be that your program simply runs as a (web) service to which you 
have access even after the customer has started to use the program. See 
http://www.paulgraham.com/road.html for a good essay on this idea.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Vesa Karvonen wrote:
> In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> wrote:
> [...]
>> I reject this comparison.  There's much more to it than that.  The point 
>> is that the reasoning which programmers perform when working with an 
>> program in a latently-typed language bears many close similiarities to 
>> the purpose and behavior of type systems.
> 
>> This isn't an attempt to jump on any bandwagons, it's an attempt to 
>> characterize what is actually happening in real programs and with real 
>> programmers.  I'm relating that activity to type systems because that is 
>> what it most closely relates to.
> [...]
> 
> I think that we're finally getting to the bottom of things.  While reading
> your reponses something became very clear to me: latent-typing and latent-
> types are not a property of languages.  Latent-typing, also known as
> informal reasoning, is something that all programmers do as a normal part
> of programming.  To say that a language is latently-typed is to make a
> category mistake, because latent-typing is not a property of languages.

I disagree with you and agree with Anton. Here, it is helpful to 
understand the history of Scheme a bit: parts of its design are a 
reaction to what Schemers perceived as having failed in Common Lisp (and 
other previous Lisp dialects).

One particularly illuminating example is the treatment of nil in Common 
Lisp. That value is a very strange beast in Common Lisp because it 
stands for several concepts at the same time: most importantly the empty 
list and the boolean false value. Its type is also "interesting": it is 
both a list and a symbol at the same time. It is also "interesting" that 
its quoted value is equivalent to the value nil itself. This means that 
the following two forms are equivalent:

(if nil 42 4711)
(if 'nil 42 4711)

Both forms evaluate to 4711.

It's also the case that taking the car or cdr (first or rest) of nil 
doesn't give you an error, but simply returns nil as well.

The advantage of this design is that it allows you to express a lot of 
code in a very compact way. See 
http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text for a nice 
illustration.

The disadvantage is that it is mostly impossible to have a typed view of 
nil, at least one that clearly disambiguates all the cases. There are 
also other examples where Common Lisp conflates different types, and 
sometimes only for special cases. [1]

Now compare this with the Scheme specification, especially this section: 
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html#%25_sec_3.2

This clearly deviates strongly from Common Lisp (and other Lisp 
dialects). The emphasis here is on a clear separation of all the types 
specified in the Scheme standard, without any exception. This is exactly 
what makes it straightforward in Scheme to have a latently typed view of 
programs, in the sense that Anton describes. So latent typing is a 
property that can at least be enabled / supported by a programming 
language, so it is reasonable to talk about this as a property of some 
dynamically typed languages.



Pascal

[1] Yet Common Lisp allows you to write beautiful code, more often than 
not especially _because_ of these "weird" conflations, but that's a 
different topic.

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Patricia Shanahan wrote:
> Vesa Karvonen wrote:
> ...
>> An example of a form of informal reasoning that (practically) every
>> programmer does daily is termination analysis.  There are type systems
>> that guarantee termination, but I think that is fair to say that it is 
>> not
>> yet understood how to make a practical general purpose language, whose
>> type system would guarantee termination (or at least I'm not aware of 
>> such
>> a language).  It should also be clear that termination analysis need not
>> be done informally.  Given a program, it may be possible to formally 
>> prove
>> that it terminates.
> 
> To make the halting problem decidable one would have to do one of two
> things: Depend on memory size limits, or have a language that really is
> less expressive, at a very deep level, than any of the languages
> mentioned in the newsgroups header for this message.

Not quite. See http://en.wikipedia.org/wiki/ACL2


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> Patricia Shanahan wrote:
>>> Vesa Karvonen wrote:
>>> ...
>>>> An example of a form of informal reasoning that (practically) every
>>>> programmer does daily is termination analysis.  There are type systems
>>>> that guarantee termination, but I think that is fair to say that it
>>>> is not
>>>> yet understood how to make a practical general purpose language, whose
>>>> type system would guarantee termination (or at least I'm not aware
>>>> of such
>>>> a language).  It should also be clear that termination analysis need not
>>>> be done informally.  Given a program, it may be possible to
>>>> formally prove
>>>> that it terminates.
>>> To make the halting problem decidable one would have to do one of
>>> two
>>> things: Depend on memory size limits, or have a language that really is
>>> less expressive, at a very deep level, than any of the languages
>>> mentioned in the newsgroups header for this message.
>> Not quite. See http://en.wikipedia.org/wiki/ACL2
> 
> What do you mean "not quite"?  Of course, Patricia is absolutely
> right.  Termination-guaranteeing languages are fundamentally less
> expressive than Turing-complete languages.  ACL2 was not mentioned in
> the newsgroup header.

ACL2 is a subset of Common Lisp, and programs written in ACL2 are 
executable in Common Lisp. comp.lang.lisp is not only about Common Lisp, 
but even if it were, ACL2 would fit.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Patricia Shanahan wrote:
> Pascal Costanza wrote:
>> Matthias Blume wrote:
>>> Pascal Costanza <[EMAIL PROTECTED]> writes:
>>>
>>>> Patricia Shanahan wrote:
>>>>> Vesa Karvonen wrote:
>>>>> ...
>>>>>> An example of a form of informal reasoning that (practically) every
>>>>>> programmer does daily is termination analysis.  There are type 
>>>>>> systems
>>>>>> that guarantee termination, but I think that is fair to say that it
>>>>>> is not
>>>>>> yet understood how to make a practical general purpose language, 
>>>>>> whose
>>>>>> type system would guarantee termination (or at least I'm not aware
>>>>>> of such
>>>>>> a language).  It should also be clear that termination analysis 
>>>>>> need not
>>>>>> be done informally.  Given a program, it may be possible to
>>>>>> formally prove
>>>>>> that it terminates.
>>>>> To make the halting problem decidable one would have to do one of
>>>>> two
>>>>> things: Depend on memory size limits, or have a language that 
>>>>> really is
>>>>> less expressive, at a very deep level, than any of the languages
>>>>> mentioned in the newsgroups header for this message.
>>>> Not quite. See http://en.wikipedia.org/wiki/ACL2
>>>
>>> What do you mean "not quite"?  Of course, Patricia is absolutely
>>> right.  Termination-guaranteeing languages are fundamentally less
>>> expressive than Turing-complete languages.  ACL2 was not mentioned in
>>> the newsgroup header.
>>
>> ACL2 is a subset of Common Lisp, and programs written in ACL2 are 
>> executable in Common Lisp. comp.lang.lisp is not only about Common 
>> Lisp, but even if it were, ACL2 would fit.
> 
> To prove Turing-completeness of ACL2 from Turing-completeness of Common
> Lisp you would need to run the reduction the other way round, showing
> that any Common Lisp program can be converted to, or emulated by, an
> ACL2 program.

Sorry, obviously I was far from being clear. ACL2 is not 
Turing-complete. All iterations must be expressed in terms of 
well-founded recursion.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Chris Uppal wrote:
> Pascal Costanza wrote:
> 
>> Sorry, obviously I was far from being clear. ACL2 is not
>> Turing-complete. All iterations must be expressed in terms of
>> well-founded recursion.
> 
> How expressive does that end up being for real problems ?   I mean obviously 
> in
> some sense it's crippling, but how much of a restiction would that be for
> non-accademic programming. 

I don't know your definition of "real problem" ;), but ACL2 is 
definitely used in industrial settings.

See 
http://www.cs.utexas.edu/users/moore/publications/how-to-prove-thms/intro-to-acl2.pdf


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:
> Anton van Straaten wrote:
>> But beyond that, there's an issue here about the definition of "the
>> language".  When programming in a latently-typed language, a lot of
>> action goes on outside the language - reasoning about static properties
>> of programs that are not captured by the semantics of the language.
>>
>> This means that there's a sense in which the language that the
>> programmer programs in is not the same language that has a formal
>> semantic definition.  As I mentioned in another post, programmers are
>> essentially mentally programming in a richer language - a language which
>> has informal (static) types - but the code they write down elides this
>> type information, or else puts it in comments.
>>
>> We have to accept, then, that the formal semantic definitions of
>> dynamically-checked languages are incomplete in some important ways.
>> Referring to those semantic definitions as "the language", as though
>> that's all there is to the language in a broader sense, is misleading.
>>
>> In this context, the term "latently-typed language" refers to the
>> language that a programmer experiences, not to the subset of that
>> language which is all that we're typically able to formally define.
> 
> That is starting to get a bit too mystical for my tastes.

To paraphrase Abelson & Sussman: Programs must be written for people to 
read, and only incidentally for compilers to check their types.

;)


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Joachim Durchholz wrote:
> Andreas Rossberg schrieb:
>>
>> Luca Cardelli has given the most convincing one in his seminal 
>> tutorial "Type Systems", where he identifies "typed" and "safe" as two 
>> orthogonal dimensions and gives the following matrix:
>>
>>   | typed | untyped
>>---+---+--
>>safe   | ML| Lisp
>>unsafe | C | Assembler
>>
>> Now, jargon "dynamically typed" is simply untyped safe, while "weakly 
>> typed" is typed unsafe.
> 
> Here's a matrix how most people that I know would fill in with terminology:
> 
> | Statically   | Not |
> | typed| statically  |
> |  | typed   |
>-----+--+-+
>typesafe | "strongly| Dynamically |
> | typed"   | typed   |
> | (ML, Pascal) | (Lisp)  |
>-+--+-+
>not  | (no common   | "untyped"   |
>typesafe | terminology) | |
> | (C)  | (Assembly)  |
>-+--+-+
> 
> (Terms in quotes are challenged on a regular basis, or rarely if ever 
> applied.)
> 
> With the above terminology, it becomes clear that the opposite if 
> "(statically) typed" isn't "statically untyped", but "not statically 
> typed". "Statically typed" and "dynamically typed" aren't even 
> opposites, they just don't overlap.
> 
> Another observation: type safeness is more of a spectrum than a clearcut 
> distinction. Even ML and Pascal have ways to circumvent the type system, 
> and even C is typesafe unless you use unsafe constructs.
> IOW from a type-theoretic point of view, there is no real difference 
> between their typesafe and not typesafe languages in the "statically 
> typed" column; the difference is in the amount of unsafe construct usage 
> in practial programs.

It's also relevant how straightforward it is to distinguish between safe 
and unsafe code, how explicit you have to be when you use unsafe code, 
how likely it is that you accidentally use unsafe code without being 
aware of it, what the generally accepted conventions in a language 
community are, etc. pp.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

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.

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.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> wrote:
>> 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.
> 
> 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?)

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.

>> 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).
> 
> It appears you've written the code above to assume that the type system 
> can't cerify that age >= 18... otherwise, the if statement would not 
> make sense.

Right.

> It also looks like Java, in which the type system is indeed 
> not powerfule enough to do that check statically.

Right.

> 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.

> If so, that's not correct.  If such a thing were checked at 
> compile-time by a static type check, then failing to actually provide 
> that guarantee would be a type error, and the compiler would tell you 
> so.

That's fine, but not relevant in this specific subplot.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> 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/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Bourguignon]

"Marshall" <[EMAIL PROTECTED]> writes:
> Yes, an important question (IMHO the *more* important question
> than the terminology) is what *programs* do we give up if we
> wish to use static typing? I have never been able to pin this
> one down at all.

Well, given Turing Machine equivalence...

I'd mention retrospective software.  But you can always implement the
wanted retrospective features as a layer above the statically typed
language.

So the question is how much work the programmer needs to do to
implement a given program with static typing or with dynamic typing.


> The real question is, are there some programs that we
> can't write *at all* in a statically typed language, because
> they'll *never* be typable? I think there might be, but I've
> never been able to find a solid example of one.

More than *never* typable, you want to identify some kind of software
that is not *economically* statically typable.

Was it costlier to develop the software developed in non statically
typed programming languages than in a statically typed programming
language?   

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"I have challenged the entire quality assurance team to a Bat-Leth
contest.  They will not concern us again."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Costanza]

Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> 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.

Yes it does. All static type systems define only a strict subset of all 
possible errors to be covered, and leave others as runtime errors. The 
same holds for dynamic type systems.

>>> 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.

I didn't know I was supposed to give a definition.

> 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.

Do you mean this one? "A type system is a tractable syntactic method for 
proving the absence of certain program behaviors by classifying phrases 
according to the kinds of values they compute." This isn't really such a 
strong definition because it shifts the problem of what exactly a type 
system is to finding a definition for the word "kind".

But if this makes you happy, here is an attempt:

"A dynamic type system is a tractable syntactic method for proving the 
absence of certain program behaviors by classifying values according to 
their kinds."

Basically, this correlates with the typical approach of using tags to 
indicate the type/kind/class of values. And indeed, this is what dynamic 
type systems typically do: they check tags associated with values. Other 
kinds of runtime errors are not raised because of such checks, but 
because of other reasons. Therefore, there is naturally a distinction 
between runtime errors that are type errors and those that are not.

I am not convinced that this definition of mine is a lot clearer than 
what I have said before, but I am also not convinced that Pierce's 
definition is any clearer either. It is merely a characterization of 
what static type systems do.

The preciseness comes into play when actually defining a type system: 
then you have to give definitions what the errors at runtime are that 
you want to prove absent by way of the static type system, give the 
typing rules for the type system, and then prove soundness by showing 
that the typing rules correlate precisely to the runtime errors in the 
first stage. Since you have to map two different views of the same thing 
to each other you have to be precise in giving definitions that you can 
then successfully use in your proofs.

In dynamic type system, this level of precision is not neces

Re: What is a type error?

[Pascal Costanza]

Marshall wrote:
> Pascal Costanza wrote:
>> Consider division by zero: appropriate arguments for division are
>> numbers, including the zero.
> 
> A bold assertion!
> 
> The general question is, what do we do about partial functions?
> 
> 
>> 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.
> 
> This is an implementation artifact, and hence not relevant to our
> understanding of the issue.

No, it's not. I am pretty sure that you can model this formally.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Marshall wrote:
>> The real question is, are there some programs that we
>> can't write *at all* in a statically typed language, because
>> they'll *never* be typable?
> 
> In a statically typed language that has a "dynamic" type, all
> dynamically typed programs are straightforwardly expressible.

What about programs where the types change at runtime?


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Marshall wrote:
> Joe Marshall wrote:
>> Marshall wrote:

>> It isn't clear to me which programs we would have to give up, either.
>> I don't have much experience in sophisticated typed languages.  It is
>> rather easy to find programs that baffle an unsophisticated typed
>> language (C, C++, Java, etc.).
> 
> C and Java, certainly, but I'm wary these days about making
> any statement about limitations on C++'s type system, for it is
> subtle and quick to anger.
> 
>> Looking back in comp.lang.lisp, I see these examples:
>>
>> (defun noisy-apply (f arglist)
>>   (format t "I am now about to apply ~s to ~s" f arglist)
>>   (apply f arglist))
>>
>> (defun blackhole (argument)
>>   (declare (ignore argument))
>>   #'blackhole)
>>
> The noisy-apply function I think I understand; it's generic on the
> entire arglist. In fact, if I read it correctly, it's even generic
> on the *arity* of the function, which is actually pretty impressive.
> True? This is an issue I've been wrestling with in my own type
> system investigations: how to address genericity across arity.
> 
> Does noisy-apply get invoked the same way as other functions?
> That would be cool.
> 
> As to the black hole function, could you explain it a bit? I apologize
> for my lisp-ignorance. I am sure there is a world of significance
> in the # ' on the third line, but I have no idea what it is.

You can ignore the #'. In Scheme this as follows:

(define blackhole (argument)
   blackhole)

It just means that the function blackhole returns the function blackhole.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Pascal Costanza wrote:
>> David Hopwood wrote:
>>> Marshall wrote:
>>>
>>>> The real question is, are there some programs that we
>>>> can't write *at all* in a statically typed language, because
>>>> they'll *never* be typable?
>>> In a statically typed language that has a "dynamic" type, all
>>> dynamically typed programs are straightforwardly expressible.
>> What about programs where the types change at runtime?
> 
> Staged compilation is perfectly compatible with static typing.
> Static typing only requires that it be possible to prove absence
> of some category of type errors when the types are known; it
> does not require that all types are known before the first-stage
> program is run.

Can you change the types of the program that is already running, or are 
the levels strictly separated?

> There are, however, staged compilation systems that guarantee that
> the generated program will be typeable if the first-stage program
> is.

...and I guess that this reduces again the kinds of things you can express.

> (It's clear that to compare the expressiveness of statically and
> dynamically typed languages, the languages must be comparable in
> other respects than their type system. Staged compilation is the
> equivalent feature to 'eval'.)

If it is equivalent to eval (i.e., executed at runtime), and the static 
type checker that is part of eval yields a type error, then you still 
get a type error at runtime!


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Pascal Costanza wrote:
>> David Hopwood wrote:
>>> Pascal Costanza wrote:
>>>> David Hopwood wrote:
>>>>> Marshall wrote:
>>>>>
>>>>>> The real question is, are there some programs that we
>>>>>> can't write *at all* in a statically typed language, because
>>>>>> they'll *never* be typable?
>>>>> In a statically typed language that has a "dynamic" type, all
>>>>> dynamically typed programs are straightforwardly expressible.
>>>> What about programs where the types change at runtime?
>>> Staged compilation is perfectly compatible with static typing.
>>> Static typing only requires that it be possible to prove absence
>>> of some category of type errors when the types are known; it
>>> does not require that all types are known before the first-stage
>>> program is run.
>> Can you change the types of the program that is already running, or are
>> the levels strictly separated?
> 
> In most staged compilation systems this is intentionally not permitted.
> But this is not a type system issue. You can't change the types in a
> running program because you can't change the program, period. And you
> can't do that because most designers of these systems consider directly
> self-modifying code to be a bad idea (I agree with them).

Whether you consider something you cannot do with statically typed 
languages a bad idea or not is irrelevant. You were asking for things 
that you cannot do with statically typed languages.

There are at least systems that a lot of people rely on (the JVM, .NET) 
that achieve runtime efficiency primarily by executing what is 
essentially self-modifying code. These runtime optimization systems have 
been researched primarily for the language Self, and also implemented in 
Strongtalk, CLOS, etc., to various degrees.

Beyond that, I am convinced that the ability to update a running system 
without the need to shut it down can be an important asset.

> Note that prohibiting directly self-modifying code does not prevent a
> program from specifying another program to *replace* it.

...and this creates problems with moving data from one version of a 
program to the next.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>> Whether you consider something you cannot do with statically typed
>> languages a bad idea or not is irrelevant. You were asking for things
>> that you cannot do with statically typed languages.
> 
> The whole point of static type systems is to make sure that there are
> things that one cannot do.  So the fact that there are such things are
> not an argument per se against static types.

I am not arguing against static type systems. I am just responding to 
the question what the things are that you cannot do in statically typed 
languages.

> [ ... ]
> 
>> Beyond that, I am convinced that the ability to update a running
>> system without the need to shut it down can be an important asset.
> 
> And I am convinced that updating a running system in the style of,
> e.g., Erlang, can be statically typed.

Maybe. The interesting question then is whether you can express the 
kinds of dynamic updates that are relevant in practice. Because a static 
type system always restricts what kinds of runtime behavior you can 
express in your language. I am still skeptical, because changing the 
types at runtime is basically changing the assumptions that the static 
type checker has used to check the program's types in the first place.

For example, all the approaches that I have seen in statically typed 
languages deal with adding to a running program (say, class fields and 
methods, etc.), but not with changing to, or removing from it.

>>> Note that prohibiting directly self-modifying code does not prevent a
>>> program from specifying another program to *replace* it.
>> ...and this creates problems with moving data from one version of a
>> program to the next.
> 
> How does this "create" such a problem?  The problem is there in either
> approach.  In fact, I believe that the best chance we have of
> addressing the problem is by adopting the "replace the code" model
> along with a "translate the data where necessary at the time of
> replacement".  Translating the data, i.e., re-establishing the
> invariants expected by the updated/replaced code, seems much harder
> (to me) in the case of self-modifying code.  Erlang got this one
> right.

...and the "translate the date where necessary" approach is essentially 
triggered by a dynamic type test (if value x is of an old version of 
type T, update it to reflect the new version of type T [1]). QED.


Pascal

[1] BTW, that's also the approach taken in CLOS.

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>>> And I am convinced that updating a running system in the style of,
>>> e.g., Erlang, can be statically typed.
>> Maybe. The interesting question then is whether you can express the
>> kinds of dynamic updates that are relevant in practice. Because a
>> static type system always restricts what kinds of runtime behavior you
>> can express in your language. I am still skeptical, because changing
>> the types at runtime is basically changing the assumptions that the
>> static type checker has used to check the program's types in the first
>> place.
> 
> That's why I find the Erlang model to be more promising.
> 
> I am extremely skeptical of code mutation at runtime which would
> "change types", because to me types are approximations of program
> invariants.  So if you do a modification that changes the types, it is
> rather likely that you did something that also changed the invariants,
> and existing code relying on those invariants will now break.

...no, it will throw exceptions that you can catch and handle, maybe 
interactively.

>> For example, all the approaches that I have seen in statically typed
>> languages deal with adding to a running program (say, class fields and
>> methods, etc.), but not with changing to, or removing from it.
> 
> Of course, there are good reasons for that: removing fields or
> changing their invariants requires that all /deployed/ code which
> relied on their existence or their invariants must be made aware of
> this change.  This is a semantic problem which happens to reveal
> itself as a typing problem.  By making types dynamic, the problem does
> not go away but is merely swept under the rug.

...and yet this requirement sometimes comes up.

>>>>> Note that prohibiting directly self-modifying code does not prevent a
>>>>> program from specifying another program to *replace* it.
>>>> ...and this creates problems with moving data from one version of a
>>>> program to the next.
>>> How does this "create" such a problem?  The problem is there in
>>> either
>>> approach.  In fact, I believe that the best chance we have of
>>> addressing the problem is by adopting the "replace the code" model
>>> along with a "translate the data where necessary at the time of
>>> replacement".  Translating the data, i.e., re-establishing the
>>> invariants expected by the updated/replaced code, seems much harder
>>> (to me) in the case of self-modifying code.  Erlang got this one
>>> right.
>> ...and the "translate the date where necessary" approach is
>> essentially triggered by a dynamic type test (if value x is of an old
>> version of type T, update it to reflect the new version of type T
>> [1]). QED.
> 
> But this test would have to already exist in code that was deployed
> /before/ the change!  How did this code know what to test for, and how
> did it know how to translate the data?

In CLOS, the test is indeed already there from the beginning. It's part 
of the runtime semantics. The translation of the data is handled by 
'update-instance-for-redefined-class, which is a generic function for 
which you can define your own methods. So this is user-extensible and 
can, for example, be provided as part of the program update.

Furthermore, slot accesses typically go through generic functions (aka 
setters and getters in other languages) for which you can provide 
methods that can perform useful behavior in case the corresponding slots 
have gone. These methods can also be provided as part of the program update.

Note that I am not claiming that CLOS provides the perfect solution, but 
it seems to work reasonably well that people use it in practice.

> Plus, how do you detect that
> some piece of data is "of an old version of type T"?  If v has type T
> and T "changes" (whatever that might mean), how can you tell that v's
> type is "the old T" rather than "the new T"!  Are there two different
> Ts around now?  If so, how can you say that T has changed?

Presumably, objects have references to their class metaobjects which 
contain version information and references to more current versions of 
themselves. This is not rocket science.

> The bottom line is that even the concept of "changing types at
> runtime" makes little sense.  Until someone shows me a /careful/
> formalization that actually works, I just can't take it very
> seriously.

Maybe this feature just isn't made for you.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reddit broke - should have remained on Lisp?

[Pascal Costanza]

[EMAIL PROTECTED] wrote:
> Kay Schluehr wrote:
>> Please, since this is a Python+Lisp cross-thread and you seem to have
>> background info: can you explain why Lisp hackers have turned
>> themselves into Python newbies for Reddit impl. and finally complain
>> about the language switch? What was cause for their decision to use
>> Python in the first place?
> 
> Basically, it was the same complaint everyone else has about common
> lisp.  It's an awesome language, but there are no reliable standard
> crossplatform (and free) libraries for threading and sockets.  They
> were using FreeBSD as a server, and (trying to) use powerbooks as a dev
> platform, and that seriously restricted viable CL implemenations.
> 
> http://redditblog.blogspot.com/2005/12/night-of-living-python.html
> http://redditblog.blogspot.com/2005/12/on-lisp.html

Compare this to that report: 
http://groups.google.com/group/comp.lang.lisp/msg/33fec2394f38546b


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: languages with full unicode support

[Pascal Bourguignon]

Joachim Durchholz <[EMAIL PROTECTED]> writes:

> Oliver Bandel schrieb:
>> Matthias Blume wrote:
>> 
>>> Tin Gherdanarra <[EMAIL PROTECTED]> writes:
>>>
>>>
 Oliver Bandel wrote:

> こんいちわ Xah-Lee san ;-)

 Uhm, I'd guess that Xah is Chinese. Be careful
 with such things in real life; Koreans might
 beat you up for this. Stay alive!
>>>
>>>
>>> And the Japanese might beat him up, too.  For butchering their
>>> language. :-)
>> OK, back to ISO-8859-1 :)  no one needs so much symbols,
>> this is enough: äöüÄÖÜß :)
>
> If you want äöüÄÖÜß, anybody else will want their local characters,
> too, and nothing below full Unicode will work.
>
> Just for laughs, here's a list of non-ASCII Latin-based letters in
> Unicode (not verified for completeness):
>   ÀÁÂÃÄÅÆàáâãäåæĀāĂ㥹ǺǻǼǽ
>   ÇçĆćĈĉĊċČč
>   ĎďĐđ
>   ÈÉÊËèéêëĒēĔĕĖėĘęĚě
>   ĜĝĞğĠġĢģ
>   ĤĥĦħ
>   ÌÍÎÏìíîïĨĩĪīĬĭĮįİıIJij
>   Ĵĵ
>   Ķķĸ
>   ĹĺĻļĽĿŀŁł
>   Ðð
>   ÑñŃńŅņŇňʼnŊŋ
>   ÒÓÔÕØòóôöõŌōŎŏÖŐőŒœǾǿ
>   ŔŕŖŗŘř
>   ŚśŜŝŞşŠšß
>   ŢţŤťŦŧ
>   ÜÙÚÛüùúûŨũŪūŭŮůŰűŲų
>   Ŵŵ
>   ÝýÿŶŷŸ
>   Þþ
>   ŹźŻżŽž
>   ƒſ
> ISO 8859-1 covers just a fraction of these, so Unicode would indeed be
> necessary to allow a program written in one country to compile in
> another one.

Indeed, far from complete:

(coerce (lschar :name "LATIN") 'string)
--> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
 ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóô
 õöøùúûüýþÿĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚěĜĝĞğĠġĢģĤĥĦħĨĩ
 ĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁłŃńŅņŇňʼnŊŋŌōŎŏŐőŒœŔŕŖŗŘřŚśŜŝ
 ŞşŠšŢţŤťŦŧŨũŪūŬŭŮůŰűŲųŴŵŶŷŸŹźŻżŽžſƀƁƂƃƄƅƆƇƈƉƊƋƌƍƎƏƐƑ
 ƒƓƔƕƖƗƘƙƚƛƜƝƞƟƠơƢƣƤƥƦƧƨƩƪƫƬƭƮƯưƱƲƳƴƵƶƷƸƹƺƻƼƽƾƿǀǁǂǃDŽDž
 džLJLjljNJNjnjǍǎǏǐǑǒǓǔǕǖǗǘǙǚǛǜǝǞǟǠǡǢǣǤǥǦǧǨǩǪǫǬǭǮǯǰDZDzdzǴǵǶǷǸǹ
 ǺǻǼǽǾǿȀȁȂȃȄȅȆȇȈȉȊȋȌȍȎȏȐȑȒȓȔȕȖȗȘșȚțȜȝȞȟȠȢȣȤȥȦȧȨȩȪȫȬȭȮ
 ȯȰȱȲȳɐɑɒɓɔɕɖɗɘəɚɛɜɝɞɟɠɡɢɣɤɥɦɧɨɩɪɫɬɭɮɯɰɱɲɳɴɵɶɷɸɹɺɻɼɽɾ
 ɿʀʁʂʃʄʅʆʇʈʉʊʋʌʍʎʏʐʑʒʓʔʕʖʗʘʙʚʛʜʝʞʟʠʡʢʣʤʥʦʧʨʩʪʫʬʭͣͤͥͦͧ
 ͨͩͪͫͬͭͮͯḀḁḂḃḄḅḆḇḈḉḊḋḌḍḎḏḐḑḒḓḔḕḖḗḘḙḚḛḜḝḞḟḠḡḢḣḤḥḦḧḨḩḪḫ
 ḬḭḮḯḰḱḲḳḴḵḶḷḸḹḺḻḼḽḾḿṀṁṂṃṄṅṆṇṈṉṊṋṌṍṎṏṐṑṒṓṔṕṖṗṘṙṚṛṜṝṞṟ
 ṠṡṢṣṤṥṦṧṨṩṪṫṬṭṮṯṰṱṲṳṴṵṶṷṸṹṺṻṼṽṾṿẀẁẂẃẄẅẆẇẈẉẊẋẌẍẎẏẐẑẒẓ
 ẔẕẖẗẘẙẚẛẠạẢảẤấẦầẨẩẪẫẬậẮắẰằẲẳẴẵẶặẸẹẺẻẼẽẾếỀềỂểỄễỆệỈỉỊị
 ỌọỎỏỐốỒồỔổỖỗỘộỚớỜờỞởỠỡỢợỤụỦủỨứỪừỬửỮữỰựỲỳỴỵỶỷỸỹⁱⁿ⒜⒝⒞⒟
 ⒠⒡⒢⒣⒤⒥⒦⒧⒨⒩⒪⒫⒬⒭⒮⒯⒰⒱⒲⒳⒴⒵ⒶⒷⒸⒹⒺⒻⒼⒽⒾⒿⓀⓁⓂⓃⓄⓅⓆⓇⓈⓉⓊⓋⓌⓍⓎⓏⓐⓑⓒⓓ
 ⓔⓕⓖⓗⓘⓙⓚⓛⓜⓝⓞⓟⓠⓡⓢⓣⓤⓥⓦⓧⓨⓩ✝✞✟fffiflffifflſtstＡＢＣＤＥＦＧＨＩＪ
 ＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊ
 ｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ"


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Pascal Bourguignon]

Chris Smith <[EMAIL PROTECTED]> writes:

> But the point here is that I don't WANT the compiler to be able to infer 
> that, because it's a transient consequence of this year's tax code.  I 
> want the compiler to make sure my code works no matter what the tax code 
> is.  The last thing I need to to go fixing a bunch of bugs during the 
> time between the release of next year's tax code and the released 
> deadline for my tax software.  At the same time, though, maybe I do want 
> the compiler to infer that tax cannot be negative (or maybe it can; I'm 
> not an accountant; I know my tax has never been negative), 

Yes, it can.  For example in Spain.  Theorically, in France IVA can
also come out negative, and you have the right to ask for
reimbursement, but I've never seen a check from French Tax
Administration...

> and that it 
> can't be a complex number (I'm pretty sure about that one).  

I wouldn't bet on it.

For example, French taxes consider "advantages in nature", so your
income has at least two dimensions, Euros and and "advantages in
nature".  Thanksfully, these advantages are converted into Euros, but
you could consider it a product by (complex 0 (- some-factor))...

> I call that 
> encapsulation, and I don't think that it's necessary for lack of 
> anything; but rather because that's how the problem breaks down.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

[EMAIL PROTECTED] writes:
> However, it is nice to work
> with friends, who know Python and not Lisp.)

It would be nicer a friendship if you taught them Lisp...

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

In a World without Walls and Fences, 
who needs Windows and Gates?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Ken Tilton wrote:

> What is up the power continuum from Lisp?

3-Lisp. ;)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> "Alex Mizrahi" <[EMAIL PROTECTED]> writes:
>> we can implement Scheme's call-with-current-continuation first :)
>> it's relatively easy -- just a code walker that coverts everyting into CPS.
> 
> It's not enough to convert to CPS, you have to be able to actually
> save the continuation when you switch to another one, so you can go
> back to the first one later.  

You get this for free once your program is in CPS. (This is true for any 
language, btw. It's just that it's easier to abstract away from the 
details of CPS in Lisp.)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

Kirk  Sluder <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]>,
>  "mystilleef" <[EMAIL PROTECTED]> wrote:
>
>> 1). More and better mature standard libraries (Languages don't matter,
>> libraries do).
> 
>> On Lisp Macros:
>> 
>> I think they are overrated, and in general cause more harm than good.
>> It's the reason I find Lisp-like programs difficult to grok, maintain
>> and extend. Cos every smart ass wants to needlessly write his own mini
>> language to the point of absolute obfuscation. Naturally, I'm supposed
>> to be awed by his mischievous cleverness.
>
> I've not seen a convincing explanation as to why imported macros 
> from some library are so much more evil than imported functions. In 
> both cases one might have to dig into documentation and/or comments 
> to understand exactly what that imported snippit is doing.

And the difference with a library function is?

(defpackage "LIBRARY" (:export "THIS-IS-A-FUNCTION"))

(library:this-is-a-function ???) ; ???

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"This statement is false."In Lisp: (defun Q () (eq nil (Q)))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

I V wrote:

> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
> With lisp, I can't do that, I have to read through the sexp, decide on
> what syntax it is, and then remind myself where to look for the relevant
> specific details.

May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
   do (print i))


This is Common Lisp. (Many Lisp and Scheme tutorials teach you that you 
should implement this using recursion, but you really don't have to. ;)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> May you have tried the wrong Lisp dialects so far:
>>
>> (loop for i from 2 to 10 by 2
>>do (print i))
> 
> The loop language is so complicated and confusing that I never
> bothered trying to learn it.

You can start with loop by using only the simple and straightforward 
constructs, and slowly move towards the more complicated cases when 
necessary. The nice thing about loop is that with some practice, you can 
write code that more or less reads like English.

 > I always used simpler primitives to
 > write loops and it was always enough.

No language construct is so simple that it cannot be replaced with a 
combination of simpler primitives.

>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
> 
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO.  I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not.  ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).

All Common Lisp implementations that I am aware of provide ways to 
enable TCO, so it's definitely possible to program in a functional style 
if you want to. It's just that the ANSI Common Lisp specification 
doesn't guarantee this, but this doesn't matter much. The only downside 
is that there is no common interface to enable TCO - that would indeed 
be an improvement. The upside is that you can switch TCO off if you want 
to, which for example may improve debugging.

It's correct that Scheme has a stronger tendency towards functional 
programming than Lisp has.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> You can start with loop by using only the simple and straightforward
>> constructs, and slowly move towards the more complicated cases when
>> necessary. The nice thing about loop is that with some practice, you
>> can write code that more or less reads like English.
> 
> Yeah, but I'd also get English-like imprecision.  Anyway, If I wanted
> to write code that reads like English, I'd write in Cobol.  

That's the neat thing in Lisp: You can stay in Lisp if you want to write 
code in a different style. No need to switch your whole tool chain.

>> All Common Lisp implementations that I am aware of provide ways to
>> enable TCO, so it's definitely possible to program in a functional
>> style if you want to. It's just that the ANSI Common Lisp
>> specification doesn't guarantee this,
> 
> Yes; I'd rather go by what the standard says than rely on
> implementation-dependent hacks.

You shouldn't limit yourself to what some standard says.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Pillsy wrote:
> Ken Tilton wrote:
> [...]
>> That was my stance for about seven years of intense Lisp. Then the
>> author of Practical Common Lisp did a nice job of breaking the whole
>> mess up into sensible chunks and I picked it up. If one programs Lisp,
>> one should learn Loop -- it is definitely worth the bother. I def regret
>> not learning it sooner.
> 
> When I first read PCL (which was my introduction to Lisp) I thought
> LOOP was really neato. Once I actually started using it for things that
> weren't so simple, I began to really hate it. I think that having a
> specialized mini-language for iteration is a superb idea, but I don't
> think LOOP is it.
> 
> That being said, there's a portable alternatives out there that I like
> way better, and I still use LOOP for dashing stuff off one-liners at
> the REPL. 

If you hate LOOP then you don't have to use it.

There's an important lesson to learn here: Not all language constructs 
are supposed to be loved by everyone. ;)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> jayessay <[EMAIL PROTECTED]> writes:
>>> It's simply that newer language designs by definition have more of an
>>> experience base to build on than older ones, if the designers care to
>>> make use of it.
>> Agreed.  Indeed, that was the underlying guiding principle in putting
>> together CL.  *ML being older than CL didn't have any more opportunity
>> in this respect.
> 
> You're forgetting that CL tried to be more or less backwards
> compatible with its predecessors, at least compatible enough that
> large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
> without too much pain.  Therefore, CL could not erase too many
> mistakes from the past.  Scheme went somewhat further than CL at
> cleaning things up, and Scheme's aficionados think CL is a clumsy old
> kludge as a result.  But it's still a Lisp dialect.  The ML's, for
> their part, were able to start from scratch.

It's funny: Language designers have been spending a lot of effort over 
the decades on designing language constructs that help to improve the 
opportunities to reuse of software libraries. Yet every five years, or 
so, new languages and technologies come up that require everyone to 
start from scratch. Starting from scratch is even being applauded, due 
to some mythical belief that "this time, we are going to get it all right."

Something seems wrong here...


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

Christophe <[EMAIL PROTECTED]> writes:

> Robert Uhl a écrit :
>> [EMAIL PROTECTED] (Aahz) writes:
>>> Consider this: Lisp has had years of development, it has had millions of
>>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>>> programmers.  Think about it.
>>
>> The argument from popularity is invalid.  French units have overtaken
>> standard units,
> Never heard of that French unit thing. Unless you talk about that
> archaic unit system that was in use before the metric system was
> created.

Who invented the metric system?

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

Paul Rubin  writes:

> André Thieme <[EMAIL PROTECTED]> writes:
>> and the Lisp version has only 9:
>> nth, 1+, truncate, signum, num, list, pos, zero, neg
>
> Oh come on, you have to count the parentheses too.

No.  Parentheses are editor commands. They don't count anymore than
spaces "count" in Python. 

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"You question the worthiness of my code? I should kill you where you
stand!"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

"Rob Thorpe" <[EMAIL PROTECTED]> writes:

> Anders J. Munch wrote:
>> jayessay wrote:
>>   > Please note: GC is not part of CL's definition.  It is likely not part
>> > of any Lisp's definition (for reasons that should be obvious), and for
>> > the same reasons likely not part of any language's definition.
>>
>> Really?  So how do you write a portable program in CL, that is to run
>> for unbounded lengths of time?
>
> You can't.

You can.  Just use reversible operations.

Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"Do not adjust your mind, there is a fault in reality"
 -- on a wall many years ago in Oxford.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are OOP's Jargons and Complexities?

[Pascal Costanza]

alex goldman wrote:
> John McGrath wrote:
> 
>>Unfortunately, there is no
>>consensus as to what the term means.
> 
> If the language allows the programmer to write programs from the 'slack'
> domain, by saying "just trust me on this", then it's not strongly typed.
> 
> What other meanings are there? I wasn't aware of the lack of consensus.

There is a difference between getting a core dump when you invoke 
undefined behavior on some object, or just getting an exception. You can 
programmatically react to an exception to do something meaningful but 
not to a core dump. Some people use the term weak typing to refer to 
languages that potentially core dump whereas they use the term strong 
typing for languages that don't.


Pascal

-- 
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I need some cleanings tips and advice.

[Pascal Bourguignon]

"Colin B." <[EMAIL PROTECTED]> writes:

> In comp.lang.perl.misc [EMAIL PROTECTED] wrote:
>> Me and my buddy made a website called www.stupidpinheads.com, its
>> basically a free forum and  free blog driven web site dedicated as a
>> source people can goto to find out how to clean and remove stains from
>> pretty much anything. Problem is, as of yet, you couldn't find out how
>> to clean anything right now cause the site is new and no one has found
>> it yet.
>
> Let's see if I get this right.
>
> You create a website for a subject that you know nothing about. Then you
> try to solicit content in a bunch of programming language newsgroups.
>
> Wow, that's pretty pathetic, even for a google-groups poster!
>
> Begone with you.

Pathetic, but it's a prooven way to become millionaire with the
Internet. You can't blame him... http://www.milliondollarhomepage.com/

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I need some cleanings tips and advice.

[Pascal Bourguignon]

Neil Cerutti <[EMAIL PROTECTED]> writes:

> ["Followup-To:" header set to comp.lang.python.]
> On 2007-06-22, Colin B. <[EMAIL PROTECTED]> wrote:
>> In comp.lang.perl.misc [EMAIL PROTECTED] wrote:
>>> Me and my buddy made a website called www.stupidpinheads.com, its
>>> basically a free forum and  free blog driven web site dedicated as a
>>> source people can goto to find out how to clean and remove stains from
>>> pretty much anything. Problem is, as of yet, you couldn't find out how
>>> to clean anything right now cause the site is new and no one has found
>>> it yet.
>>
>> Let's see if I get this right.
>>
>> You create a website for a subject that you know nothing about. Then you
>> try to solicit content in a bunch of programming language newsgroups.
>>
>> Wow, that's pretty pathetic, even for a google-groups poster!
>
> Maybe they lost the business plan. It's not surprising, since it
> was probably written on a napkin.

No problem with that, we can help:


  +-+
  |  BUSINESS PLAN  |
  +-+
 *%*


 1-  Make a web site about stains

 2-  ???

 3-  Profit!



-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Twisted <[EMAIL PROTECTED]> writes:

> On Jun 21, 12:09 pm, Robert Uhl <[EMAIL PROTECTED]> wrote:
>> Twisted <[EMAIL PROTECTED]> writes:
>>
>> >> > I have that exact URL now --
>> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> >> Utterly unrelated to Emacs.
>>
>> > I think it is quite relevant. Clunky computer interfaces may not be so
>> > dramatically dangerous, but they certainly can hamper productivity.
>>
>> You're quite right.  Windows/Mac user interfaces are so clunky that they
>> massively hamper productivity.
>
> This is a joke, right?

How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Falcolas <[EMAIL PROTECTED]> writes:

> On Jun 22, 3:06 pm, Pascal Bourguignon <[EMAIL PROTECTED]> wrote:
>> How do you call a Mac user interface that let a user work during 3
>> hours to do a simple modification to a MS-Word file that takes 15
>> seconds to do with emacs or a simple unix script?
>
> Would you mind elaborating on *what* took 3 hours to do, as opposed to
> just throwing around unquantified numbers? Would you also mind
> explaining the user's familiarity with the tools they were using on
> the mac?

Anything that the user have to do repeatitively with the GUI, like
copy-and-paste, or reformating of a lot of paragraphs or table
entries, and which is done automatically by writting a one-liner
program in emacs or shell.

And they tried to put graphical user interfaces on scripting, it
doesn't work either.  Programming is working with text, with verbs.


> It's just as easy for me to say that it took me 30 minutes to simply
> exit emacs, and use that to justify that emacs, and by extension
> Linux, is a terrible tool.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: terminology buffer and keybinding

[Pascal Bourguignon]

Twisted <[EMAIL PROTECTED]> writes:
> The Windows world may have a fair bit to learn from the Unix world
> about software reliability and QA, and also about better supporting
> task automation. But not about user interface design for when tasks
> are done manually.

That's the point.  Manual tasks have nothing to do in computers.
Computers are there to automatize tasks, not to give you more manual work.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/

NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Lisp-like macros in Python?

[Pascal Costanza]

Converge is a Python-style language with a macro facility. See 
http://convergepl.org/

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft's Dynamic Languages Runtime (DLR)

[Pascal Costanza]

sturlamolden wrote:
> On Monday Microsoft announced a new runtime for dynamic languages,
> which they call "DLR". It sits on top of the conventional .NET runtime
> (CLR)  and provides services for dynamically typed languages like
> Python or Lisp (thus the cross-posting). Apparently is is distributed
> under a BSD-like open-source license.
> 
> I am curious to know how it performs in comparison to CPython and an
> efficient compiled Lisp like CMUCL. Speed is a major problem with
> CPython but not with .NET or CMUCL, so it will be interesting to see
> how the DLR performs in comparison. It would be great to finally see a
> Python that runs on steroids, but knowing M$ bloatware my expectations
> are not too high.
> 
> Has anyone looked at the DLR yet? What are your impression?

So far, there is not a lot of information available. The only statement 
about the technology I have read so far is that the DLR is a thin layer 
on top of the CLR. This doesn't say a lot.

So it's hard to tell whether this is a (good) marketing stunt or whether 
there are actual substantial improvement to the infrastructure.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft's Dynamic Languages Runtime (DLR)

[Pascal Costanza]

Fuzzyman wrote:
> On May 2, 8:20 pm, Pascal Costanza <[EMAIL PROTECTED]> wrote:
>> sturlamolden wrote:
>>> On Monday Microsoft announced a new runtime for dynamic languages,
>>> which they call "DLR". It sits on top of the conventional .NET runtime
>>> (CLR)  and provides services for dynamically typed languages like
>>> Python or Lisp (thus the cross-posting). Apparently is is distributed
>>> under a BSD-like open-source license.
>>> I am curious to know how it performs in comparison to CPython and an
>>> efficient compiled Lisp like CMUCL. Speed is a major problem with
>>> CPython but not with .NET or CMUCL, so it will be interesting to see
>>> how the DLR performs in comparison. It would be great to finally see a
>>> Python that runs on steroids, but knowing M$ bloatware my expectations
>>> are not too high.
>>> Has anyone looked at the DLR yet? What are your impression?
>> So far, there is not a lot of information available. The only statement
>> about the technology I have read so far is that the DLR is a thin layer
>> on top of the CLR. This doesn't say a lot.
>>
>> So it's hard to tell whether this is a (good) marketing stunt or whether
>> there are actual substantial improvement to the infrastructure.
> 
> Well, they're now implementing four dynamic languages on top of the
> DLR - not just IronPython.
> 
> * IronPython
> * IronRuby
> * Java Script
> * VBx (a dynamic version of VB)
> 
> The DLR provides a dynamic type system and hosting environment for
> dynamic languages.
> 
> The nice part is that the DLR runs on top of the 'Core CLR' which
> ships with Silverlight. This means that apps. that run in Silverlight
> are secure - so you can run an IronPython console in the browser...

That still doesn't explain what DLR actually does. You can implement 
these languages on top of the JVM as well. You could implement them on 
any Turing-complete language, for that matter. The interesting question 
how well integrated such an implementation is.

However, Jim Hugunin seems to be willing to give more details on his 
blog - the recent entry gives hints that there is indeed something 
interesting going on. I'm still waiting for the meat, though...


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why stay with lisp when there are python and perl?

[Pascal Costanza]

Jon Harrop wrote:

> It is worth noting that eager, statically-typed languages like OCaml and F#
> are many times faster than the other languages at this task. This is
> precisely the forte of OCaml and F#, manipulating trees and graphs.

Here is a page that sums up some important observations about 
benchmarks: http://www.ccs.neu.edu/home/will/Twobit/bmcrock.temp.html

Especially:

- "With modern superscalar architectures, 5-level memory hierarchies, 
and wide data paths, changing the alignment of instructions and data can 
easily change the performance of a program by 20% or more, and Hans 
Boehm has witnessed a spectacular 100% variation in user CPU time while 
holding the executable file constant. Since much of this alignment is 
determined by the linker, loader, and garbage collector, most individual 
compiler optimizations are in the noise. To evaluate a compiler 
properly, one must often look at the code that it generates, not the 
timings."

- "The execution time of a program is often dominated by the time spent 
in very small pieces of code. If an optimizing compiler happens to do a 
particularly good job of optimizing these hot spots, then the program 
will run quickly. If a compiler happens to do an unusually poor job of 
optimizing one or more of these hot spots, then the program will run 
slowly."

- "If the hot spots occur within library routines, then a compiler may 
not affect the performance of the program very much. Its performance may 
be determined by those library routines."

- "The performance of a benchmark, even if it is derived from a real 
program, may not help to predict the performance of similar programs 
that have different hot spots."



Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

[CfP] Dynamic Languages Symposium 2007

[Pascal Costanza]

*
*
*   Dynamic Languages Symposium 2007
*
*at ooPSLA 2007 - http://www.oopsla.org
*
*
*
*  Montreal, Quebec, Canada, October 22, 2007
*
*
*
*   http://www.swa.hpi.uni-potsdam.de/dls07/
*
*
*


Important dates:


* Submission of papers: June 1, 2007 *hard deadline*
* Author notification:  June 30, 2007
* Final versions due:   July 7, 2007
* DLS 2007: October 22, 2007
* OOPSLA 2007:  October 21-25, 2007

Scope:
**

The Dynamic Languages Symposium (DLS) at OOPSLA 2007 in Montreal,
Canada, is a forum for discussion of dynamic languages, their
implementation and application. While mature dynamic languages
including
Smalltalk, Lisp, Scheme, Self, and Prolog continue to grow and inspire
new converts, a new generation of dynamic scripting languages such as
Python, Ruby, PHP, and JavaScript are successful in a wide range of
applications. DLS provides a place for researchers and practitioners
to
come together and share their knowledge, experience, and ideas for
future research and development.

DLS 2007 invites high quality papers reporting original research,
innovative contributions or experience related to dynamic languages,
their implementation and application. Accepted Papers will be
published
in the OOPSLA conference companion and the ACM Digital Library.

Areas of interest include but are not limited to:
*

* Innovative language features and implementation techniques
* Development and platform support, tools
* Interesting applications
* Domain-oriented programming
* Very late binding, dynamic composition, and runtime adaptation
* Reflection and meta-programming
* Software evolution
* Language symbiosis and multi-paradigm languages
* Dynamic optimization
* Hardware support
* Experience reports and case studies
* Educational approaches and perspectives
* Object-oriented, aspect-oriented, and context-oriented programming

Submissions and proceedings
***

We invite original contributions that neither have been published
previously nor are under review by other refereed events or
publications. Research papers should describe work that advances the
current state of the art. Experience papers should be of broad
interest
and should describe insights gained from substantive practical
applications. The program committee will evaluate each contributed
paper
based on its relevance, significance, clarity, and originality.

Papers are to be submitted electronically at
http://www.dcl.hpi.uni-potsdam.de/dls2007/ in PDF format.
Submissions must not exceed 12 pages and need to use the ACM format,
templates for which can be found at
http://www.acm.org/sigs/pubs/proceed/template.html.

Program chairs:
***

* Pascal Costanza, Programming Technology Lab,
   Vrije Universiteit Brussel, Belgium

* Robert Hirschfeld, Hasso-Plattner-Institut,
   University of Potsdam, Germany

Program committee:
**

* Gilad Bracha, Cadence Design Systems, USA
* Johan Brichau, Universite Catholique de Louvain, Belgium
* William Clinger, Northeastern University, USA
* William Cook, University of Texas at Austin, USA
* Pascal Costanza, Vrije Universiteit Brussel, Belgium
* Stephane Ducasse, Universite de Savoie, France
* Brian Foote, Industrial Logic, USA
* Robert Hirschfeld, Hasso-Plattner-Institut Potsdam, Germany
* Jeremy Hylton, Google, USA
* Shriram Krishnamurthi, Brown University, USA
* Michele Lanza, University of Lugano, Switzerland
* Michael Leuschel, Universitaet Duesseldorf, Germany
* Henry Lieberman, MIT Media Laboratory, USA
* Martin von Loewis, Hasso-Plattner-Institut Potsdam, Germany
* Philippe Mougin, OCTO Technology, France
* Oscar Nierstrasz, University of Berne, Switzerland
* Kent Pitman, PTC, USA
* Ian Piumarta, Viewpoints Research Institute, USA
* Nathanael Schaerli, Google, Switzerland
* Anton van Straaten, AppSolutions.com, USA
* Dave Thomas, Bedarra Research Labs, Canada
* Dave Ungar, USA
* Allen Wirfs-Brock, Microsoft, USA
* Roel Wuyts, IMEC & Unversite Libre de Bruxelles, Belgium

-- 
http://mail.python.org/mailman/listinfo/python-list

Subclass str: where is the problem?

[pascal . parent]

Hello, can anybody explain/help me:

Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2


class Upper(str):
  def __new__(cls, value):
return str.__new__(cls, value.upper())

u = Upper('test')
u
'TEST'
type(u)

u = Upper('')
u
''
type(u)



All seems to be ok...

class MyObject(object):
  def __init__(self, dictionary = {}):
self.id = dictionary.get('id', '')
  def __setattr__(self, attribute, value):
value = type(value) is type('') and Upper(value) or value
object.__setattr__(self, attribute, value)

m = MyObject({'id': 'test'})
m.id
'TEST'
type(m.id)

m = MyObject()
m.id
''
type(m.id)


Why is m.id a str ?
Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Subclass str: where is the problem?

[pascal . parent]

This is good... try this:

value = 'test'
value
'test'
type(value)

value = type(value) is type('') and Upper(value) or value
value
'TEST'
type(value)
 

value = 1
value
1
type(value)

value = type(value) is type('') and Upper(value) or value
value
1
type(value)


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Subclass str: where is the problem?

[pascal . parent]

Effectively.
Thanks a lot Peter and Harold.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Pascal Bourguignon]

"[EMAIL PROTECTED] opalinski from opalpaweb" <[EMAIL PROTECTED]> writes:

>> Simply put, tabs is proper, and spaces are improper.
>> Why? This may seem
>> ridiculously simple given the de facto ball of confusion: the semantics
>> of tabs is what indenting is about, while, using spaces to align code
>> is a hack.
>
> The reality of programming practice trumps original intent of tab
> characters.  The tab character and space character are pliable in that
> if their use changes their semantics change.
>
>> ... and the solution is to advance
>> the sciences such that your source code in some way
>> embed such information.
>
> If/when time comes where such info is embeded perhaps then tabs will be
> OK.
>
> ---
>
> I use spaces because of the many sources I've opened I have many times
> sighed on opening tabed ones and never done so opening spaced ones.
>
> I don't get mad, but sighing is a clear indicator  of negativity.
> Anyway, the more code I write and read the less indentation matters to
> me.  My brain can now parse akward source correctly far bettter than it
> did a few years ago.

And anyways, C-x h C-M-\ comes automatically after C-x C-f source RET 
Just add this to your ~/.emacs :

(add-hook 'find-file-hook
   (lambda () (indent-region (point-min) (point-max)) (pop-mark)))



-- 
__Pascal Bourguignon__ http://www.informatimago.com/

IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
-- 
http://mail.python.org/mailman/listinfo/python-list