Ben Hinkle wrote:
> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com...
> 
>>... how about nothing?
>>
>>a = b[3..];
>>
>>For a kind of consistency:
>>
>>a = [0..3] or
>>a = [..3];
> 
> This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember. 

Most of the time (not always, but most of the time), when we're slicing relative to the end of the array, we're slicing to the very end.  Do we really require to have a shortcut for slicing short of that?  It seems to me that we could, quite reasonably, require that for the unusual case (slicing short of the end) they have to use the full, written out version.

So I would argue that maybe it's time to resurrect the b[3..] syntax. Frankly, I liked b[3..length], and I'm not sure that it's something that we have to change.  But if we're going to change it, then let's do something that reads easily for a newbie, and not some PERL-esque nightmare like $.

On Fri, 11 Mar 2005 10:54:56 -0700, Russ Lewis wrote:

> Ben Hinkle wrote:
>> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com...
>> 
>>>... how about nothing?
>>>
>>>a = b[3..];
>>>
>>>For a kind of consistency:
>>>
>>>a = [0..3] or
>>>a = [..3];
>> 
>> This was suggested but I can't find the posts about it. The issue is that you want to use length/$/whatever in arbitrary expressions inside the brackets. Basically one wants a shortcut for writing array.length. The 'nothing proposal' isn't general enough. It might also have parsing issues but I can't really remember.
> 
> Most of the time (not always, but most of the time), when we're slicing relative to the end of the array, we're slicing to the very end.  Do we really require to have a shortcut for slicing short of that?  It seems to me that we could, quite reasonably, require that for the unusual case (slicing short of the end) they have to use the full, written out version.
> 
> So I would argue that maybe it's time to resurrect the b[3..] syntax. Frankly, I liked b[3..length], and I'm not sure that it's something that we have to change.  But if we're going to change it, then let's do something that reads easily for a newbie, and not some PERL-esque nightmare like $.

It would seem I'm a lucky person as I've never used, nor even read, anything in PERL. A non-alpha symbol such as '$' doesn't frighten me nor give me any concern. It seems I'm become accustomed to such beasties such as + * - ! & |, so $ isn't such a biggie for me to cope with.

On the other hand, no one is forcing me to use $ either.

<humor attempt=on>
May be we should also introduce alternate syntax so we have the option to
remove other naked non-alpha tokens from our code?

   add varA to varB giving varC end-statement

instead of

   varC = varB + varB;

</humor>


-- 
Derek Parnell
Melbourne, Australia
12/03/2005 8:04:08 AM

Derek Parnell wrote:
> It would seem I'm a lucky person as I've never used, nor even read,
> anything in PERL. A non-alpha symbol such as '$' doesn't frighten me nor
> give me any concern. It seems I'm become accustomed to such beasties such
> as + * - ! & |, so $ isn't such a biggie for me to cope with.
> 
> On the other hand, no one is forcing me to use $ either.
> 
> <humor attempt=on>
> May be we should also introduce alternate syntax so we have the option to
> remove other naked non-alpha tokens from our code?
> 
>    add varA to varB giving varC end-statement
> 
> instead of 
> 
>    varC = varB + varB;
> 
> </humor>

I am not in the least opposed to using non-alpha tokens in code.  They make the code shorter, and thus, often, easy to read.  However, some tokens that we use are trivial for a newbie to read because they have history in algebra or other sciences; thus, the code is easy to read from the start.  Others, like ~ or %, the newbie just has to learn by rote.  I argue that the language should resist using these types of tokens - use them, yes, but use them only for a really important need.

My reference to PERL was not a criticism of using non-alpha tokens; it was, instead, intended as a criticsim of using arbitrary syntaxes to give syntax sugar.  For every such proposal, propoents can argue that "hey, it's only one more thing to write, and it will make my code MUCH easier," but after you've done it a few times, the language becomes an unintelligible nightmare of esoteric gibberish.  Few PERL programmers know all of the odd shortcuts, so each programmer can write some sort of "cool" program that will confuse most other programmers.

There must be a compelling case for every syntax sugar.  IMHO, there isn't one for $.

Derek Parnell wrote:

> <humor attempt=on>
> May be we should also introduce alternate syntax so we have the option to
> remove other naked non-alpha tokens from our code?
> 
>    add varA to varB giving varC end-statement
> 
> instead of 
> 
>    varC = varB + varB;
> 
> </humor>

It's actually a good thing, trying to protect Freedom of Programming...

Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt


But better done by tools, of course.
--anders


PS. http://www.nosoftwarepatents.com/

In article <d0t5g1$jvn$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>It's actually a good thing, trying to protect Freedom of Programming...
>
>Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt
>

My God, its full of words!

- EricAnderton at yahoo

On Fri, 11 Mar 2005 23:18:41 +0100, Anders F Björklund wrote:

> Derek Parnell wrote:
> 
>> <humor attempt=on>
>> May be we should also introduce alternate syntax so we have the option to
>> remove other naked non-alpha tokens from our code?
>> 
>>    add varA to varB giving varC end-statement
>> 
>> instead of
>> 
>>    varC = varB + varB;
>> 
>> </humor>
> 
> It's actually a good thing, trying to protect Freedom of Programming...
> 
> Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt
> 
> 
> But better done by tools, of course.

Oh that was just beautiful. That is going on the office wall for sure!

-- 
Derek Parnell
Melbourne, Australia
12/03/2005 4:21:43 PM

In article <nivnsmu7c3h8$.scp3dzyhlp43.dlg@40tude.net>, Derek Parnell says...
>
>On Fri, 11 Mar 2005 23:18:41 +0100, Anders F Björklund wrote:
>
>> Derek Parnell wrote:
>> 
>>> <humor attempt=on>
>>> May be we should also introduce alternate syntax so we have the option to
>>> remove other naked non-alpha tokens from our code?
>>> 
>>>    add varA to varB giving varC end-statement
>>> 
>>> instead of
>>> 
>>>    varC = varB + varB;
>>> 
>>> </humor>
>> 
>> It's actually a good thing, trying to protect Freedom of Programming...
>> 
>> Like http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/css-auth.babel-eng.txt
>> 
>> 
>> But better done by tools, of course.
>
>Oh that was just beautiful. That is going on the office wall for sure!


I have a friend who would occasionally (late at night, and well into a rowdy party) grab a page or two of my C-listings and read it aloud, slowly, as if it were poetry. With gratuitous pause for effect before the inevitable "... semicolon ... carriage-return"

People would join in, like a chorus, on the latter. Especially those who had a drink in both hands :~)

Then we'd throw him into the pool.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0qfbh$35p$1@digitaldaemon.com...
>
> "Charlie Patterson" <charliep1@excite.com> wrote in message news:d0qcva$kt$1@digitaldaemon.com...
> > ... how about nothing?
> This was suggested but I can't find the posts about it.

It's hard to search for nothing <g>.

> The issue is that
> you want to use length/$/whatever in arbitrary expressions inside the
> brackets. Basically one wants a shortcut for writing array.length. The
> 'nothing proposal' isn't general enough. It might also have parsing issues
> but I can't really remember.

It starts causing a lot of parsing problems when the expressions become non-trivial.