Re: Proposal for adding variable declaration blocks

On Jul 18, 2008, at 11:52 AM, Simetrical wrote:

> On Fri, Jul 18, 2008 at 2:41 PM, James Elmore  
> <James.Elmore@cox.net> wrote:
>> 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
>
> I got it from Wikipedia, and I think it's an amusing term, so I'll  
> go with it.
>
> http://en.wikipedia.org/wiki/Sigil_(computer_programming)

Thanks for the reference. I knew what it meant, but could not  
remember having seen it used before.

>
>> 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>
>
> If some kind of sigil is used, there's no reason to prevent keywords
> from being used in variable names.

Agree, but would wish it were not so because of prior experience with  
overlapping names in programming languages which allow that sort of  
thing. It just makes reading the code harder.

>   The sigil will effectively
> distinguish variables from keywords.  For comparison, other
> implementations I'm aware of (PHP and bash, mainly) reserve no
> variable names -- $function, $while, and so on are perfectly valid.
> (Both do predefine certain variables before the program begins
> executing, but those variables can generally be changed like any
> other.)
>
> With the huge number of keywords CSS uses, it seems like a good idea
> to avoid conflicts, as I remarked previously.  In some contexts,
> $color would be a very reasonable choice for a variable name.  I don't
> think you'd have to be an idiot at all.

Sorry for the poor example. My point was that using identical (except  
for a sigil, possibly) names lead to mental overlap and will  
eventually cause problems, based on my experiences. Perhaps others  
are smarter and can avoid these problems, but I find they almost  
always pop up.

<style>
     declare { $font: Times, New Times, serif; }
     p { font: $font 12px blue; }
</style>

Maybe that points out the confusion better than 'color'. At any rate,  
overloading (the psychological term) causes mental fatigue and, if  
enough people are involved will trip someone up and cause problems  
which are harder to find than they need to be. I just prefer  
(personal preference, based on experiences I have no wish to repeat)  
that keywords be excluded.

>
> As for whether to use the sigil in the declarations as well, I don't
> think there would be any difference in terms of parsing it, in the
> syntaxes that have been contemplated so far.  I think it's more
> intuitive to use the same name in declaration and use, not require an
> extra character for one but not the other.

Some languages I have used have gone one way, some the other. For the  
earliest systems I know, the preference was avoiding typing, so the  
extra character (sigil) was excluded from the declaration and only  
used when the variable was referenced. In some later languages, the  
preference was reversed (maybe the programmers could type faster?) so  
that every invocation of the variable (including declarations) was  
identical.

In terms of parsing, if the sigil is not present, then standard CSS  
syntax would declare the use of keywords invalid, otherwise a  
declaration might just be a CSS selector with a selector for an  
element of type 'declare'

(Inventing on the fly: <quote> <author>Patrick Henry</ 
author><declare>Give me liberty or give me death!</declare></quote>)

<style>
     declare {color: red;}
     em { color: $color; }
</style>

That would fail, because $color was not declared. (The "declare  
{ ... }" would be interpreted as a standard syntax unless the parser  
was carefully made to handle this exception.

In that case, the parser would need something like @declare to  
recognize a variable. If keywords were excluded, the parser might be  
able to tell the difference and avoid the extra characters (@ and $).

I guess, looking back, that I am over-thinking this. Surely some of  
you with CSS parser experience can tell me which syntax makes the  
most sense.

</James>

Received on Friday, 18 July 2008 21:02:49 UTC