Re: Proposal for adding variable declaration blocks

On Jul 18, 2008, at 10:40 AM, Simetrical wrote:

>
> On Fri, Jul 18, 2008 at 12:28 AM, Brad Kemper  
> <brkemper@comcast.net> wrote:
>> I do not understand the argument others have made that a dollar  
>> sign would
>> be more natural. To me it is just another abstract symbol without  
>> anything
>> to make it more understandable as a variable identifier. Is it  
>> because in
>> some programming languages it is used to denote string-type  
>> variables?
>
> In several languages it's used for all variables.  Shell scripts and
> PHP prefix all variable names with $.  Perl prefixes all scalar
> variable names with $ (with different sigils for lists and maps).
> It's therefore a very natural convention to those who are used to
> scripting languages, unless they only do Python and Ruby, or something
> like that.  For instance, in PHP or Perl the following is a syntax
> error:
>
> var = 7;
>
> You need to do this:
>
> $var = 7;

Going back into the misty, prehistoric times of early programming,  
BASIC also used '$' to denote a variable. (I suspect it had something  
to do with the serpent in the Garden of Eden climbing a tree ;-)

>
> Since a fairly large percentage of web authors probably know a little
> PHP, it seems like a reasonable point to bring up.  If variables are
> prefixed with $, some nontrivial percentage of people will immediately
> get the syntax on first sight, while = will have to be learned anew by
> everyone (unless there's someplace I know of that uses it for
> variables).  And the same goes in the other direction, of course:
> people used to $-prefixed variables in CSS will be more comfortable
> with that convention in other languages.  If there's going to be some
> abstract sigil used for variables, it may as well be one that's
> already used in other standards.
>
> =varname seems weird to me.  It would be a syntax error in practically
> any programming language, since = is generally used for something
> else.  It seems more natural to me to reserve = for equality testing
> and/or assignment, or to use it in places that are clearly not at all
> similar to existing programming constructs, to avoid confusion.
>
> Of course, CSS is not a programming language and a large percentage of
> its users are not programmers, but a large percentage are or will be
> programmers, and it is a computer language.  If some preexisting
> knowledge can be leveraged, I think that's good.  But it's not really
> a big deal, in the end: it's a pretty trivial distinction to learn.
>

Even if CSS is not a programming language, at some point, an equality  
test will probably be needed. If the '=' is already used for this  
construct, it will make the parser much harder to build, and the  
parsing rules much harder to understand.

By the way, (possibly I missed this) is there a suggestion about  
using the variable sigil (interesting word -- I would use indicator)  
for the variable in all cases, or only when it is dereferenced? I  
will try to fabricate an example. If I mess up the syntax, I  
apologize in advance.

<style >
	declare { HeadColor: #ff00aa; }
	h1 { color: $HeadColor; }
</style>

The first use of HeadColor is what I would call assignment. Setting a  
value in the variable. Most parsers call it the LHS -- left hand side  
(of the equals sign in a programming language).

The second use is getting the value of the variable and placing it  
somewhere. In a parser, I would think of it as the RHS -- right hand  
side.

Would it make CSS parsing easier if every use of the variable (LHS  
and RHS; setting and getting) required a sigil? Or would that make  
things more complex, because then idiots could do things like:

<style>
     declare { $color: #00ff00; }
     h1 { color: $color; }
</style>

In the first example (HeadColor), the parser would be able to detect  
and declare the use of an existing keyword (or any reserved word) in  
a variable name as an error. This prevents people from reusing  
keywords and confusing themselves and anyone who attempts to read  
their code.

In the second example ($color), there would be lots of reasons to  
allow *any* identifier as a variable name and, although the parser  
might still complain about reusing keywords, it is harder to justify  
calling it an error.

The purpose of CSSwg is not to be the thought police, and if there  
are strong reasons for allowing idiots to reuse keywords -- providing  
the sigil is present -- then I would say, let them. But if the parser  
is simpler and if we can reasonably restrict the reuse of keywords as  
variables, that would be my recommendation, if only to protect the  
innocents who must follow and attempt to repair problems the idiots  
create.


</James>

Received on Friday, 18 July 2008 18:42:40 UTC