Re: foreach enhancement

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

From: Michael C (nospam_at_lol.net)
Date: 07/18/04 

Date: Sun, 18 Jul 2004 01:53:31 GMT

"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.

>
> 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]

>
> 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.

> 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...

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: Best way to enumerate something in python
    ... I found out range creates lists not tuples, ... changed (for an enum type approach). ... i did some reading and if i interpreted this correctly, dictionaries are ... >> I'm wondering about the best way to enumerate something. ...
    (comp.lang.python)
  • Re: foreach enhancement
    ... > typed lists and strongly typed lists; ... >> This is where the compiler comes in. ... > automatically break down and enumerate string objects in the List. ... does what I do want *without* causing this behaviour in strings. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Discrete Math and Prolog
    ... So I envision a Prolog system with a more general ... Enumerate the integers in a range. ... Enumerate the ordered sub lists of a list: ... The solve will be used to turn an arbitrary predicate into an iterator. ...
    (comp.lang.prolog)
  • Re: Tired of 100s of stupid Getter/Setter methods
    ... > lists, and dicts as built-in types, and their contents are not ... > except the language is designed intelligently so doing that does not ... let the compiler find out more about types. ... contains Strings -- that generics are worth it for that alone. ...
    (comp.lang.java.programmer)