Compilers - Non-declared Variables

Author

Non-declared Variables

Avatar

2006-10-16, 10:00 pm

I would like to hear people's opinions on the ability to use variables
without declaring them in dynamic languages like Ruby.

It would seem to me that an argument for non-declared local variables
that typically occupy a small scope could be made. But, class
variables? What is the benefit in allowing for runtime definition of
class variables?

Are there real tangible benefits that non-declared, dynamically typed
(at binding time) variables provide? Or do dynamic variables simply
create less compile time errors and more (harder to catch) runtime
errors?

Thoughts?

Wolfram Fenske

2006-10-17, 4:01 am

"Avatar" <acampbellb@hotmail.com> writes:

> I would like to hear people's opinions on the ability to use variables
> without declaring them in dynamic languages like Ruby.
>
> It would seem to me that an argument for non-declared local variables
> that typically occupy a small scope could be made. But, class
> variables? What is the benefit in allowing for runtime definition of
> class variables?
>
> Are there real tangible benefits that non-declared, dynamically typed
> (at binding time) variables provide? Or do dynamic variables simply
> create less compile time errors and more (harder to catch) runtime
> errors?
>
> Thoughts?

You could use this to support functionality that resembles the factory
pattern. Instead of writing a bunch of boiler plate code, you supply
a description of the class you want to create and the factory method
takes care of defining the actual attributes and methods of the class.
Plone, a web-based content management framework written in Python does
that. Here's an example (sorry if it's a bit long):

--8<---------------cut here---------------start------------->8---
# -*- coding: iso-8859-1 -*-
#
# $Id: ECQBaseQuestion.py,v 1.2 2006/08/14 11:39:14 wfenske Exp $
#
# Copyright 2004 Otto-von-Guericke-Universitt Magdeburg
#
# This file is part of ECQuiz.
#
# ECQuiz is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# ECQuiz is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with ECQuiz; if not, write to the Free Software Foundation,
# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

[...] (snipped imports)

class ECQBaseQuestion(ECQFolder):
""" A very basic question type without any evaluation functions.

A question is basically a question text and a set of possible
answers to this question or, in Plone terms, a folder with
some additional properties such as the question text.
"""

schema = ECQFolder.schema.copy() + Schema((
StringField('title',
required=False,
searchable=True,
default='Question',
widget=StringWidget(
label_msgid='label_title',
description_msgid='title',
i18n_domain='plone'),
read_permission=PERMISSION_STUDENT,
),
InlineTextField('question',
searchable=True,
required=True,
primary=True,
allowable_content_types=('text/plain',
'text/structured',
'text/restructured',
'text/html',),
default_output_type='text/html',
widget=TextAreaWidget(
label='Question',
label_msgid='question_label',
description='The question text. This is what the '
'candidate will see.',
description_msgid='question_tool_tip',
i18n_domain=I18N_DOMAIN,
rows=10,
),
validators=('isXML',),
read_permission=PERMISSION_STUDENT,
),
),
)

# Use a custom page template for viewing.
suppl_views = None
default_view = immediate_view = 'ecq_basequestion_view'

aliases = updateAliases(ECQFolder, {
'view': default_view,
})

# This prevents the Questions from showing up as a portal content
type
global_allow = False
# Only Answer objects may be put into this folder.
allowed_content_types = (ECQBaseAnswer.portal_type,)

meta_type = 'ECQBaseQuestion' # zope type name
portal_type = meta_type # plone type name
archetype_name = 'Base Question' # friendly type name

content_icon = 'ecq_question.png'

security = ClassSecurityInfo()

#security. declareProtected(PERMISSION_INTERROGATOR
,
'contentValues')
#security. declareProtected(PERMISSION_INTERROGATOR
,
'listFolderContents')
# Declaring "folderlistingFolderContents" as protected prevents
# the answers from being listed if someone without
# PERMISSION_INTERROGATOR tries to call the "base_view" template
# for a question.
security. declareProtected(PERMISSION_INTERROGATOR
,
'folderlistingFolderContents')

security.declareProtected(PERMISSION_STUDENT, 'UID')

security.declarePrivate('makeNewTest')
def makeNewTest(self, candidateResult, suMode):
"""generate a new quiz"""
# This is just to register the question with result object
candidateResult.setSuggestedAnswer(self, None)

security.declareProtected(PERMISSION_STUDENT,
'haveCandidateAnswer')
def haveCandidateAnswer(self, result):
"""
@param result A Result object
"""
return result.haveCandidateAnswer(self)

# Register this type in Zope
registerATCTLogged(ECQBaseQuestion)
--8<---------------cut here---------------end--------------->8---

The important part is the "schema" attribute of the class. It is the
main definition of the class. When this class definition is
registered in the system (via "registerATCTLogged") it gets new
instance attributes called "title", "question" and the corresponding
getters and setter, "getTitle", "setQuestion" etc., among other
things. Plone is a web-based CMF, so instances of this class can be
displayed in a browser. The way it'll look is also defined in the
schema. E. g., when you edit the "question" attribute, a
"TextAreaWidget" with 10 rows will be used and the input will be
validated using the "isXML"-validator (which is imported from another
file). There is other stuff I could explain, but I think you get the
idea.

IMO this is way better and less error-prone than having to write lots
of boring code by hand. But I have a hunch that it is mostly a
work-around for Python's lack of Lisp-style macros. I havn't
completely thought this through but the idea is this: the class
definition is in fact known statically, it just doesn't follow
Python's syntax. In Lisp I could write a macro that tranforms the
schema-syntax into a class definition that Lisp understands. This
transformation could happen at compile-time. But Python doesn't have
a macro mechanism so the transformation has to be done at runtime, by
dynamically adding attributes and methods. If Python didn't allow
that, Plone's schema-mechanism would probably be impossible to
implement. There may be other scenarios where adding attributes and
methods to classes at runtime would be useful, ones that can't be
covered by Lisp macros, but I havn't encountered them so far (which
doesn't say much). Maybe somebody else knows an example.

Wolfram

gnorik@gmail.com

2006-10-30, 7:32 pm

I don't think that it is a good idea when language definition allows
you to use variables without declaration.
First of all, it leads to bugs which is rather hard to find.
You may do a type, and write, let's say instead of myvar, mywar, and
thus mywar most likely don't equal to myvar (probably it will be
initialized as zero) you already have a bug.
Secondly, when people used to declare variables they know what they are
doing. They know that if they need a one byte variable, or two, or four
byte variable, then they don't have to allocate space for a whole
string, as done in most of scripting languages starting from basic, and
still in perl, tcl, etc...

Regards

Norayr Chilingaryan

---
http://geocities.com/n0rayr

"Avatar
"
> I would like to hear people's opinions on the ability to use variables
> without declaring them in dynamic languages like Ruby.

Quinn Tyler Jackson

2006-10-30, 7:32 pm

> I don't think that it is a good idea when language definition allows
> you to use variables without declaration.

I think languages should forbid the declaration of variables, for the
following reasons:

Required declaration of variables...

* ... leads to the programmer jumping to conclusions about what a variable
is for.
* Code doesn't need no declaration telling a compiler what it can and cannot
do.
* ... puts the responsibility for correctness on the human beings, and human
beings are fallible.
* Type mismatch errors during compilation inhibit creativity.
* ... because it's redundant to introduce syntactic sugar into a language
when there is already a mechanism in place to state intended use of a
variable: comments.
* ... puts undo weight on variables, bringing them to others' attention and
de-emphasizing the algorithm.
* ... de-emphasizes the Wikipedian notion of "eventualism" ("the program
will eventually be correct if it's important enough to make it so, and a
mass of coders will make it correct one day if it's notable") and emphasizes
"immediatism" ("the program must work correctly NOW or it is useless.")
* ... increases inter-line dependencies: variables declared on line n first
used on line n+j, for some increasing value of j over time as code gets
tweaked.
* ... requires compiler technologies to remember too much information they
could use probabilistic methods to guess at.
* ... gives a false sense of correctness: all code is wrong somewhere, so
why dress it up and present it as being "more correct" -- correctness is an
absolute, not a scale.
* ... is disempowering: who's to say that variable's right to self
determination should be usurped by some declaration? Let it decide its own
eventual fate.
* ... is too prematurely legalistic: when a coder declares what a variable
"is" -- he or she is presuming to know what the meaning of "is" is.
* ... puts too much responsibility on other code for being correct, causing
resentment between lines.
* ... is stifling to system evolution: if someone comes along later and
wants to change a variable's type, he or she must then do an impact study to
see what might break. Since evolving systems are broken anyway, this deters
progress by overemphasizing and dictating that those breaks be in the more
important parts: the system logic, rather than the less important parts: the
administratrivia.

TPFIC

--
Quinn Tyler Jackson

Peter Flass

2006-10-30, 7:32 pm

gnorik@gmail.com wrote:
> I don't think that it is a good idea when language definition allows
> you to use variables without declaration.
> First of all, it leads to bugs which is rather hard to find.

I would expect the compiler to issue a message for this, unless
undeclared variables are the norm for this language, as in Rexx. PL/I,
for example, has language-specified defaults and default rules, but all
compilers I know of also warn.

ArarghMail610@Arargh.com

2006-10-30, 7:32 pm

On 26 Oct 2006 00:28:58 -0400, Peter Flass <Peter_Flass@Yahoo.com>
wrote:

>gnorik@gmail.com wrote:
>
>I would expect the compiler to issue a message for this, unless
>undeclared variables are the norm for this language, as in Rexx. PL/I,
>for example, has language-specified defaults and default rules, but all
>compilers I know of also warn.

MS Basic 16-bit compilers for the most part, didn't.

Come to think of it, I don't think that the 32-bit ones do either.

The exception to that is that some support an "OPTION EXPLICIT" which
causes an error for undeclared variables, when used.
--
ArarghMail610 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
[BASIC never required declarations, even for arrays. -John]

Pascal Bourguignon

2006-10-30, 7:32 pm

Quinn Tyler Jackson <qtj-query@shaw.ca> writes:

>
> I think languages should forbid the declaration of variables, for the
> following reasons:
> [...good reasons...]

But there's one thing where you need to declare the variables, it's
when you have lexical scope.

{
x=0;
{
x=1;
print x;
}
print x;
}

What does this print? Is there one or two variables? What about : {{
x=1; } print x;} and other such cases? Of course you can have only
dynamic variables and no lexical scope.

But I think the conclusion reached 20 years ago was that having only
dynamic scope without lexical scope was bad, and even that it'd be
better to have only lexical scoping...

That said, in lisp for example, we don't really declare the variables,
we directly bind them:

(let ((x 0))
(let ((x 1))
(print x))
(print x))

and we get printed 0 and 1.

[Additionnal declarations can be inserted, but are optional.

(let ((x 0))
(declare (type integer x)
(special x))
(let ((x 1.0))
(declare (type float x))
(print x))
(print x))
]

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

"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."

Sponsored Links