In our previous episode, J?rgen Hestermann said: [ Charset ISO-8859-15 unsupported, converting... ] > >> p > > The value of a pchar. > > What do you mean by "value"? The pointer or the character it is pointing > to? It seems that p sometimes means the first and sometimes the latter.
The pointer. The character (the pointer is pointing to) is not of type pchar. The pointer has an own typedefinition and value too, and is a real type, not a mere syntax element > >> p^ > > the char pointed to. > > Is this the same as p? No. > > I don't think you can say anything from pure syntax without bringing in the > > typing. The fact that the pointer type required ^ in the past so that you > > could make the distinction in this case is therefore negiable. > > I don't understand what you mean here. If I write a constuct (like "p") > it should mean the same in all circumstances. Otherwise it's becoming > tricky when you need to think about the context too when writing code. "p" without anything could be an integer, real, string, pointer type. IOW to really read the code you need to know the typing. > >> To put one on top, the meaning is even context dependent (using it in an > >> expression or as a paramater of a function may give it have different > >> meanings). > > True, but that is due to additional conversions in the expression, not the > > strict meaning of the notation. > > Again I don't understand what you mean with "additional conversions". If When using certain types that can automatically convert to others in expressions or such types in combination with overloading, sometimes unintuitive things happen. I thought you were hinting on that. > I want to access a pointer or its address or the data it is pointing to > I should have an unambiguous, uniform and different syntax for all these > 3. But this is no longer the case. I don't see your point here. > >> I am not sure why following the strict logic would generate more work. > > Because when you are converting, (and then I mean manual or semi-automatic, > > because reliable automatic conversion is hard), then the small errors that > > this leads to can cost you days of debugging work. > > Why that? In Turbo Pascal times I often coded complex nested data > structures with records, arrays and pointers pointing to them. Then it > often happened that I accidentaly used a pointer where I should have > used the dereferenced pointer (or vice versa) but the compiler > immediately raised an error and showed it to me. Now the compiler starts > beeing smarter than I am and guesses what I could have meant. That's not > very debugging friendly. As far as I know, the additional syntax has nothing to do with error detection. This is an argument that is IMHO dragged in by the hairs. One can argue out of orthogonality, esthetic or intuitive reasons, but afaik there is no ambiguity on the compiler level here. > > That bit of code: yes. However not having these is not an option either, > > since it makes interfacing costly and hard to maintain, which is why these > > features trickled in. And you are incompatible with Delphi and also MUST > > convert there.... (not entirely true, some of them were in FPC first, due to > > its own particular needs) > > Regarding arrays and pointers I can't see your problems. If in C a > pointer is required you can use one in Pascal too. C allows to drop the * by transfering to array syntax. So Pascal allows droping the ^ in places where it doesn't matter (when not at the end of the expression) > > If it hadn't been for Delphi compatibility, the extensions maybe could be > > limited to a certain mode, or unit type. (since modes are nowadays global > > per unit, if there was no delphi compatibility, the dialect selection could > > be in the unit declaration) > > Yes, Borland was the culprit who introduced all this to Pascal. I was > realy disappointed about it at that time. But Free Pascal is no longer a > slave of Borland so could correct their errors. No. Compatibility is way more important to really getting things done. One can debate if it is worthwhile in implementing (bits of) the recent syntaxes, but the codebases in say the D7 dialect are simply too big to discard. It would disallow any significant exchange and communication with the Delphi community. > > I don't think a handful of extensions are that bad. If it bothers you so > > much, submit patches for directives to turn them on/off. > > If I would change my code only I would have an island solution. Reading > code from others (for example Lazarus source code) would still be a > problem. It is already a problem that no Pascal standard exits anymore. You could separate the kind of code that needs this (interfacing code) from code that doesn't. Removing it is no option, not now, not ever, because of existing codebases and Delphi. > Adding yet another variant is not good. I once thought that Pascal was > superior to other languages because of it's clear and strict concept but > now there is no longer *the* Pascal language anymore. It never was. UCSD derivates were never fully compatible with the standard and had a more pragmatic stance. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
