Re: foreach enhancement

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 07/18/04 

Date: Sat, 17 Jul 2004 21:14:22 -0500

"Michael C" <nospam@lol.net> wrote in message
news:vKkKc.36915$Kz3.3539609@news4.srv.hcvlny.cv.net...
>
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:#xdtPYGbEHA.2340@TK2MSFTNGP10.phx.gbl...
>
>> Again, I see no reason why you can't merge this into one keyword. Two
>> different compiled representation of one keyword is irrelevent as long as
>> the *semantic* and effective behaviour is the same.
>
> See other post. As long as you're willing to differentiate between weakly
> typed lists and strongly typed lists; or prohibit weakly typed lists
> altogether; and don't care about optimization hints, it isn't necessary
> and
> one keyword is just fine.
>
>> >
>> > Well... if we're dealing with single-type lists, implicit typing should
>> > not
>> > be an issue at all, as the reference variable should be explicitly
>> > typed
>> > anyway. As in
>> >
>> > int i;
>> > [yield i for [1..1000]]
>>
>> IMHO, I'd like to find a way where the variable exists only *within* the
>> list, just as for and foreach loops work now.
>>
>
> Simple.
>
> [yield int i for [1..1000]]
>
> Since it's declared within the scope of the list iterator, it exists only
> within that scope just like a for loop.

That sitll doesn't explain how to return i*2.
[yield int i*2 for[1...1000]] doesn't make a whole lot of sense.

>
>>
>> This is where the compiler comes in. There are quite a few tricks that
>> can
>> be pulled off by the compiler without the user being able to tell the
>> difference.
>> Consider these loops: ...
>> In esscense its entirely possible to optimize and still maintain 1...100
> as
>> a enumerator. That particular magic is unsurprising, consisitent and
>> benificial, unlike some other bits.
>> It also makes this optimization optional, as not supporting it results in
>> code that is semantically identical.
>>
>
> This makes perfect sense when dealing with ranges and lists composed only
> of
> ranges. Just one question - how would it handle the following:
>
> [1..10]
> [1,2,3,4,5,6,7,8,9,10]

Explained that in the other post, we should probably merge these into one
sometime soon before things get confusing, LOL.
>
>>
>> If a list generated by [ ] can accept some enumerable expressions, it
> would
>> have to accept them all. I'm really unsure of how to approach this. If
>> 1...1000 is an enumerable expression, then wouldn't you expect
>> IEnumerable<int> x = 1...1000
>> [x]
>> to mean the same as
>> [1...1000]?
>>
>> following that logic,
>> List<int> x = new List<int>();
>> x.Add(1);
>> x.Add(2);
>> x.Add(3);
> ...
>>
>> should that result in the same list?
>>
>> if you say yes to all of these, then why wouldn't
>> ["water"]
>> and
>> ['w','a','t','e','r']
>> be the same?
>
> For one, "water" is not, by definition, a range. Since we're talking
> about
> expected results here, do you really expect that "water" should present an
> enumerable Range of values like 1..1000? Or that List.Add("water") should
> produce the same result as
>
> List.Add('w');
> List.Add('a');
> List.Add('t');
> List.Add('e');
> List.Add('r');
>
> I think the difference we're talking about here is the difference between
> enumerable objects and enumerable Ranges. By definition, I would think
> that
> a Range is composed of objects, and that the enumeration of a List would
> not
> automatically break down and enumerate string objects in the List.
> Although
> if the user wanted to address the individual list objects, they could
> obviously enumerate them... Themselves, and one at a time.

Howeve,r you miss a point. List.Add *doesn't* support adding ranges in any
way, shape, or form. *EVERYTHING* is a single object. If List.Add did double
duty, adding both ranges and single items you would probably have a similar
problem(the compiler choosing Add(IEnumerable) over Add(object) when you
pass it a string). It *NEVER* has to make a descision about what to do, its
behaviour is well defined and mapped out. As things stand with this list
syntax there is no clear definition that results in expected behaviour.

Also, to make a point, what I expect isn't the issue. I certainly don't want
strings to behave this way. The problem is I can't find a set of rules that
does what I do want *without* causing this behaviour in strings.

The issue really is, what is a range? Is a range simply a shortcut that
makes lists and some loops easier or is it a general purpose construct that
expresses a range of values? If its hte former you can throw this all away
and end up with significantly less flexibility, if its the former you have
to find a set of rules taht allows its flexibility without compromising
anything else.

>
>> I think you miss the point. The issue isn't that strings wn't work in
>> ranges, they certainly don't make sense in them. The point is that a
> string
>> is indistiguishable from any other range when viewed through IEnumerable
>> colored glasses.
>
> See, difference of opinion - I think you miss the point.
>
> Again, I go back to ArrayLists. ArrayLists are IEnumerable. You can add
> strings to them. The ArrayList, during enumeration does not break down
> the
> string into its component chars. So why is the eyeglass prescription so
> different for a List when compared to other IEnumerables?
>
> Especially since, unlike ArrayList, we're looking at *strongly* typed
> lists... It's not like we're going to enumerate a list and hit <int>,
> <int>, <string>... You know in advance whether it's a list of strings or
> a
> list of ints, right? With that knowledge, why would enumerating a
> strongly-typed list of strings be a problem? Especially since we already
> know in advance that we can't define a range of strings; so we know in
> advance that if we have a list of strings we're not going to enumerate
> them
> into their individual chars or bits or other weirdness...

You know ahead of time while enumerating, but the lists type is implicitly
determined from its contents. Just as the compiler infers that 1 is an
integer in most cases, it would infer that [1] is a list of integers. Thus,
the compiler decides what type the list is based on the contents of the
list, and thus it can't use the type of the list to determine how to use the
contents of said list.

This is a departure from standard C# behaviour, where everything is
explicitly typed, but I can't think of a really good way to do it any other
way. Ideally the object would support both IList<T> and IList<object> where
applicable, but that really is a different matter altogether.

Now, I'll give you taht you could explicitly ignore string when processing
IEnumerables, however that breaks consistency. Instead of saying "any
IEnumerable expression", it becomes "any IEnumerable expression except those
typed string" which is tricky, IMHO.

Relevant Pages

  • Re: Symbols, metacircular evaluation, external representation.
    ... You could only use strings, and you would have to use parsers all the time. ... same kind of symbolic expressions, it's very easy to write functions ... writting a metacircular interpreter (or a lisp compiler), ... lists. ...
    (comp.lang.scheme)
  • Re: How come Ada isnt more popular?
    ... are praising is, because what about trees of strings, trees of lists etc. ... a language also shouldn't have strings ... but there are no generics instantiated. ...
    (comp.lang.ada)
  • Re: How come Ada isnt more popular?
    ... are praising is, because what about trees of strings, trees of lists etc. ... the language should not have either X or Y built-in. ... but there are no generics instantiated. ...
    (comp.lang.ada)
  • Re: Newb looking for data binding help
    ... lists to store the strings, ... Two strings, one for a system name and one for equipment name ... When the user clicks on an 'equipment' node, I'd like to display just ...
    (microsoft.public.dotnet.languages.vb)
  • Bottleneck rule
    ... groups similar strings together. ... prints out an intermediate store file to view intermediate results. ... (setf (aref store i 0) ... ;;Print output the lists of grouped strings and counts. ...
    (comp.lang.lisp)