Received: by 10.150.219.16 with SMTP id r16mr1199010ybg.19.1226022349872;
        Thu, 06 Nov 2008 17:45:49 -0800 (PST)
Return-Path: <rober...@math.washington.edu>
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19])
        by mx.google.com with ESMTP id 22si3556006yxr.1.2008.11.06.17.45.49;
        Thu, 06 Nov 2008 17:45:49 -0800 (PST)
Received-SPF: pass (google.com: domain of rober...@math.washington.edu designates 140.142.33.19 as permitted sender) client-ip=140.142.33.19;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of rober...@math.washington.edu designates 140.142.33.19 as permitted sender) smtp.mail=rober...@math.washington.edu
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged))
	by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id mA71jmj8004193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <sage-devel@googlegroups.com>; Thu, 6 Nov 2008 17:45:48 -0800
X-Auth-Received: from [192.168.0.105] (c-76-28-156-184.hsd1.wa.comcast.net [76.28.156.184])
	(authenticated authid=robertwb)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id mA71jlNa004498
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <sage-devel@googlegroups.com>; Thu, 6 Nov 2008 17:45:48 -0800
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <8eed31cd-e9c8-4791-86ab-20ebfd4f3d81@40g2000prx.googlegroups.com>
References: <face9d89-2b8e-43b6-997e-7cd325300663@p31g2000prf.googlegroups.com>  <A362C97E-9801-4505-986C-EDAD113751DA@mac.com> <e2a76927-2f63-431b-a3c3-b1f0ebab15cd@c22g2000prc.googlegroups.com>  <85e81ba30811020918u1ad88e6es1fd4e06097c08805@mail.gmail.com>  <4bf94fa1-fb36-4075-8c6e-d5784ff8b75d@e38g2000prn.googlegroups.com>  <85e81ba30811021124y792217faq9a5ced87fa5b8f72@mail.gmail.com>  <158627b90811021222n192b4717k32fb5457efe22a37@mail.gmail.com>  <85e81ba30811021253o434b7f2cre27069cfa806786a@mail.gmail.com> <8eed31cd-e9c8-4791-86ab-20ebfd4f3d81@40g2000prx.googlegroups.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AF0117CC-DBE2-44A3-AA02-C8302E5FE...@math.washington.edu>
Content-Transfer-Encoding: 7bit
From: Robert Bradshaw <rober...@math.washington.edu>
Subject: Re: [sage-devel] Re: Why Sage needs var(...) commands unlike  Mathematica?
Date: Thu, 6 Nov 2008 17:45:44 -0800
To: sage-devel@googlegroups.com
X-Mailer: Apple Mail (2.753.1)
X-PMX-Version: 5.4.3.345767, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.7.13710
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'

On Nov 3, 2008, at 8:05 AM, Robert Dodier wrote:

> William Stein wrote:
>
>> Incidentally, if we did allow automatic creation of symbolic
>> variables, and default calling of symbolic expressions, then
>> doing something like this would happen
>> all the time and confuse the crap out of people:
>>
>> sage: function_name_with_slight_typo(10)
>> 10
>
> Well, that's weird, but it's not weird because of automatically
> creating a variable for function_name_with_slight_typo.
> Calling symbolic expressions -- that's weird.

For me the question is not so much what is "weird" but rather what  
behavior has the most potential for strange, subtle bugs. The nature  
of the "symbolic ring" to try and accept and absorb about anything  
makes this much worse--especially as I'd rather get an immediate  
error. For me Sage is much more than an environment to manipulate  
expressions, but a scriptable computation engine. Also, Sage being  
typed with many various parents and other objects makes it more  
natural to require the user to declare things ahead of time.

>> I think it would be interesting to have at least the capability
>> of a mode where variable names are made symbolic if
>> not previously used, at least if the calling behavior were redefined
>> as above.  This would have be done by somehow parsing the
>> input, finding all undefined variables, defining them, etc....
>> It's techincaly possible.  Maybe Fernando Perez and I can
>> try to make a demo of something like this at Sage Days 11.
>
> I would be inclined to plug in a custom top-level interpreter loop
> which just catches NameError and instantiates suitable variables
> and reevaluates the input when that happens. Is there a way to
> get Python to parse the input without evaluating it? (Isn't there
> an AST package or s.t.l.t. which could do that?) Then you could
> (I guess) detect undefined variables without causing side-effects
> from any part of the input. Just a guess -- I'm no expert on Python.

There is, see http://www.python.org/doc/2.5.2/lib/module- 
compiler.html . Tools are even provided to "walk" the tree, so one  
could, for example, easily extract all (undeclared, non-declaration)  
NameNodes and define them to be symbolic variables before evaluating  
the code. Much better than introducing possible side effects with  
repeated re-evaluation. (Of course, I would expect this as an  
optional mode.)

I see this thread has somewhat diverged from the original topic in  
the last couple of days, but I think a lot of the grief could be  
saved via better documentation. I created http://trac.sagemath.org/ 
sage_trac/ticket/4458 . Once you know what a NameError means,  
declaring things is an easy fix.

- Robert