[solved] macro for code ?

[MarkMLl]

No need to be sorry, I also fall for this bait from time to time. Others have pointed out the usual pollutants here more than once, so I won't.

[GUFFAW]

Actually, there's one thing I think I can usefully tack in for completeness.

Shewhosenameshallnotbespoken asked about where a (parameterless) macro can be defined: a year or so ago I experimented with putting it in the Lazarus IDE project options and was able to report that that didn't work, so macros /have/ to be defined in the context of the current unit (including included .inc files).

I'd also comment that nested macros are expanded usefully. Recursion is left as an exercise...

MarkMLl

[Joanna from IRC]

This has certainly been an interesting discussion 
I suppose there has to be a way for the computer to store set elements behind the scenes. I am surprised to be told that I can iterate from lowest to highest element though. Is that true? All this time I’ve thought that only for in loop can be used for sets.

[MarkMLl]

This has certainly been an interesting discussion 
I suppose there has to be a way for the computer to store set elements behind the scenes.

Yes, and as an implementation detail- not a part of the language per se- there can be (a) a restriction on the number of elephants in a set and (b) a point below which they can be assumed to be stored sequentially (e.g. in a machine word) but above which they are not (e.g. in a hashed tree of buckets).

It is not uncommon to find CS texts that advocate wildly inefficient storage in an attempt to avoid any size limitation.

I am surprised to be told that I can iterate from lowest to highest element though. Is that true? All this time I’ve thought that only for in loop can be used for sets.

Look at it like this. Assuming something like your earlier example

Code: Pascal  [Select][+][-]

1. for x in theSet do
2. ...
3.  

assume that you're actually iterating over all possible values of the (type associated with) the variable x, and then testing to see whether the value is a member of theSet.

That's OK if x is declared as a reasonably small enumeration or subrange, not at all OK if it's a large numeric type.

Finally, the ordering issue also affects databases: a lot of people are content to assume that an unindexed database will always return rows in the same order, but this is not safe and will depend both on decisions made by the query engine and on the storage mechanism being used.

MarkMLl

[440bx]

It's interesting that code like this:

Code: Pascal  [Select][+][-]

1. for x in theSet do
2. ...
3.  

would not be possible if the set wasn't internally ordered.

but.. why would  anyone care about internals ???  ... ignorance is such a bliss!...  I hope I didn't hurt somebody's fragile feelings again...

[MarkMLl]

It's interesting that code like this:

Code: Pascal  [Select][+][-]

1. for x in theSet do
2. ...
3.  

would not be possible if the set wasn't internally ordered.

It would be entirely possible, based on the ordering of the base type... as I said, and as Alpine said earlier.

Application of <= etc. to a set is not arithmetic, and does not imply any ordering.

MarkMLl

[Joanna from IRC]

Thanks for the answers. It seems like there is contention About the true nature of a set. I am more concerned with actually using it as set although the inner workings of it are interesting too I don’t think it should be misused.

[440bx]

It would be entirely possible, based on the ordering of the base type... as I said, and as Alpine said earlier.

NO, it would not.   The base type order isn't sufficient. 

It is necessary to order the set elements the same way they are ordered in the base type.  That's what makes it work.  IOW, the compiler has to assign a specific bit to represent a specific element.  That's the ordering and, of course, the simplest and most straightforward implementation is to use the ordinal of the base as the bit index.

How often does the obvious have to be explained ????

I even posted some code somewhere that shows how the compiler orders the elements.

[MarkMLl]

Thanks for the answers. It seems like there is contention About the true nature of a set. I am more concerned with actually using it as set although the inner workings of it are interesting too I don’t think it should be misused.

By and large, it's safe to assume that any Pascal implementation will permit "set of char", at least until that's broken by somebody defining char to map onto some ridiculous Unicode type rather than ansichar.

I'd throw in that Modula-2 has a bitset type which is defined as mapping onto the bits of a machine word, you can rely on that being ordered but not necessarily in the direction you'd expect (some implementations call the LSB 0, others call the MSB 0).

MarkMLl

[PascalDragon]

Thanks for the answers. It seems like there is contention About the true nature of a set. I am more concerned with actually using it as set although the inner workings of it are interesting too I don’t think it should be misused.

By and large, it's safe to assume that any Pascal implementation will permit "set of char", at least until that's broken by somebody defining char to map onto some ridiculous Unicode type rather than ansichar.

Fun fact: Current Delphi implicitly converts set of Char with Char = WideChar to set of AnsiChar together with a warning that it did this (and set of WideChar triggers an error).

[MarkMLl]

Fun fact: Current Delphi implicitly converts set of Char with Char = WideChar to set of AnsiChar together with a warning that it did this (and set of WideChar triggers an error).

Ouch!

MarkMLl

[TRon]

but.. why would  anyone care about internals ???  ... ignorance is such a bliss!...  I hope I didn't hurt somebody's fragile feelings again...

Which is why real programmers read and comprehend documentation. Ignorance must indeed be such a bliss. Better is ofc to waste time with those indirect insults.

[440bx]

Which is why real programmers read and comprehend documentation. Ignorance must indeed be such a bliss. Better is ofc to waste time with those indirect insults.

It's not an insult, it's worse, it's a fact.  Anyone who has read documentation knows that it very rarely covers every detail, it's up to the programmer (well... I should say, some programmers) to go beyond what is documented.  Again, that's not an insult, that's a fact.

Just like, internally, FPC orders the elements that make up a set (can't say that sets are ordered because apparently it isn't obvious that it is their elements that are ordered) and it is at least good to be aware of that, because "for" loops absolutely need to have the elements they act on to be ordered for them to operate properly.

Is it really that hard to gather knowledge beyond what is documented ?  Just for the record, a lot of programmers don't find it difficult and in addition to that, some even find it rewarding. 

Let's state the obvious again, by definition sets are collections of unordered elements, HOWEVER, for performance and implementation simplicity reasons, Pascal DOES order set elements.   Is it really that hard to comprehend that ?   

[Thaddy]

ISO 7185:
"Set types
Set types are perhaps the most radical feature of Pascal. A set type can be thought of as an array of bits indicating the presence or absence of each value in the base type:

var s: set of char;
Would declare a set containing a yes/present or no/not present indicator for each character in the computer's character set. The base type of a set must be ordinal."

Pascal sets are therefor ordered as opposed to the mathematical definition of sets. It is NOT,  as often suggested, implementation detail.
Freepascal throws an error if an attempt is made to make the set not ordered because of that. Technically it is a bitset.
At compile time it renders a note, at runrime it throws a runtime error:

Code: Pascal  [Select][+][-]

1. program setdemo1;
2. type
3.   TTest1 = (a,b=4,c=3);// unordered, can't be used for sets.
4.   TTest2 = (aa,bb,cc); // ordered
5.   TTestSet1 = set of TTest1;
6.   TTestSet2 = set of TTest2;
7. var
8.   t1:TTest1;
9.   t2:TTest2;  
10. begin
11.   for t2 in TTestSet2 do writeln(t2);// OK
12.   for t1 in TTestSet1 do writeln(T1);// runerror 107: invalid enumeration
13. end.

[MarkMLl]

Yes, but the ordering is by virtue of the ordinal base type. It says nothing about the ordering of the storage.

MarkMLl

[Thaddy]

Yes, but the ordering is by virtue of the ordinal base type. It says nothing about the ordering of the storage.

MarkMLl

The ordering is mandatory for sets and documented in ISO 7185.
As per my demo, the compiler is aware of that.