[fpc-pascal] "is"

[Marco van de Voort]

> >>	<< do something with elem >>
> >>end;
> >>[...]
> > 
> > True, BUT... hmm, I actually have 3 BUTS
> 
> It is some sort of syntactic sugar, so all your but's are valid at least 
> in some way. Nobody ever doubted this.

Good.
 
> > BUT 1: some form shorter syntax can be thought up for _each_ _and_
> > [...]
> > 
> > BUT 2: The whole purpose of iterators is that you can have multiple orders
> >on the same object, and get a different iterator to get a different order.
> 
> I disagree, the main purpose of iterators is to provide uniform 
> iteration over containers (e.g. to use the same code to iterate over 
> different collections).
> That there are different types of iterators (forward, backward, and 
> random access, readonly, writeable, ...) is definitely a feature of a 
> specific iterator imo.

I'm more thinking on different properties. E.g. on address, on name etc. 

> If you have to program differently for every container (for i := low(x) 
> to ..; for i := 0 to count-1 ...; etc. etc.) only makes code harder to 
> understand and error prone without additional gain.

I don't buy that kind of arguments. This is Pascal, not Matlab. You
need to have a general idea about is what happening, and knowledge about
typing is a fundament of a strongly typed language. Note that I name Matlab
and not VB. Contrary to popular myth, you need to have a pretty good sense
about what is happening in VB too, at least if your program is non-trivial.
 
> Additionally if you examine code, _far_ the most applications do simple 
> forward (and maybe backward) iteration over a collection (also because 
> there are not that much collections where random access makes sense 
> runtime-wise).

My point was that if you invent syntax, at least make it somewhat general.
However that is pretty much the point of this extension. A few people knew
this construct from VB, which has no sane syntax anyway, and complained
about the two extra keystrokes. It has nothing to do with design or thinking
about a nice, general solution.
 
> So maybe it is feasible to enhance the syntax to the following (BNF this 
> time):
> 
> foreachstatement ::=
>    "foreach" element "in" container ["forwards" | "backwards"] "do"
>    statement.

foreach element in container[.interface] do
  statement

with interface the a property that returns an interface to the iterator,
one being default 

However this is all just trying to find justification to implement it. I
brought the point up to show that the syntax wasn't really thought about,
just plain copied.
 
> *ducks into cover, awaiting flames* =)

IMHO this time to find arguments to justify something stupid as for..each
and MI interfaces should better be invested in researching a documenting a
possible implementation for generics. At least that opens a scala in
possibilities, and is not simply trying to avoid two keystrokes of typing,
that could be solved with an IDE macro/template anyway.
 
> You are right, it _is_ syntactic sugar. Never doubted it. But iterators 
> may be an important tool in programming which may justify inclusion into 
> the language.

Then come with a nice library design that does iterators in a sane way. With
possible extensions. Then we might have a sane talk about it.
 
> > while lightmapiterateover(iter) do
> >  << do something with lightmapgetobject(iter)>>
> > // no finalisation of iter necessary.
> >  
> > Is this so bad ? I don't see the problem
> 
> I'm not sure that I'm interpreting your code sequence correctly, but I 
> don't consider this design as very good either (maybe driven by 
> implementation considerations though) - you lost abstraction over the 
> container type which forces the programmer to learn the correct commands 
> for every type of container (which isn't too hard assuming that they are 
> pretty similar - but there is no real *gain* for doing that. And you 
> don't lose anything when you do it the other way)

You might notice that the names are exactly DECAL notation with type
prefixed. However decal (an interface based implementation) was painfully
slow. A decal <string,objects> map is slower than a sorted tstringlist,
which is already not really a performance wonder.

> The finalization is a pure design issue, depending on the capabilities 
> of the container (thread safety, safe for container modification, ...) 
> which may be needed to properly release used resources. This is an option.

Indeed.
 
> Additionally you lost type safety (e.g. missing the typecast of the 
> retrieved object =).

There is only one solution for that. Generics. Not a custom solution for
every point were it might occur.

> Taking all that into account there isn't much difference in typing 
> between the two proposals, isn't there?

IMHO not in all three, since it is all invoking a template to me :)