sergio masci wrote: >>> It is now clear to me that you are talking about intrinsic >>> functions. Yes the function is defined in a /standard/ library but >>> the compiler also knows about the function independently of the >>> library. >> >> Would you call the C++ standard library functions (like >> std::list::insert) "intrinsic functions"? At least the meaning that >> this term seems to have in the Microsoft VC++ and gcc compiler >> documentation is not what I'm talking about. > > No. But this is what I'm talking about. So I was right with my suspicion that I wasn't talking about what you called "intrinsics". > home in on "'knows' the intent of the line" This is what I'm trying to do. This is the reason why I want to understand what it is that makes a function that is defined by the standard (and is implemented in a library) different from a construct that is defined in the same standard and implemented inside the compiler. I haven't yet seen an example by you that I could understand -- and that wasn't about something else. [Snipped string loop optimization example.] > So here the compiler looked at several statements as a single unit and > was able to optimise it (this is quite within the capabilities or > modern C compilers). Or other languages... something like this seems to be standard in good compilers. > It is far easier for you, me and the compiler to understand the > programmers intent if instead I write: > > X = X + Y; Agreed. >> Right. My point was that if 8-bit strings are built-in and Unicode >> strings are in a library, and you are claiming (elsewhere) that the >> built-in syntax can be different from library syntax, then I need to >> make the Unicode string syntax completely different -- structurally >> different -- from 8-bit string syntax. Can you imagine that? What a >> pain. > > Yes you are right it would be a pain. But it is a move in the right > direction. I'm not sure. I think I wouldn't like it. For example, it seems that for some things Pascal-style strings are more efficient than C-style strings. There's nothing that prevents me from working with Pascal-style strings efficiently in C++ (and no matter whether ASCII, 8-bit with different codepages, different encodings of Unicode) -- in the same idiom that is used for standard strings in C++. This is because strings are /not/ built into the language (among other things). Being able to work with similar types in a similar way is important for code quality. If you need to use a different idiom for different string encodings, code quality goes down -- and code quality is important. > I think I understand what you mean. But just to clarify: You are > suggesting that instead of simply defining a function as: > > substr(char *, int); > substr(char *, int, int); > > That I could instead write: > > substr(char * 'FROM' int); > substr(char * 'FROM' int 'TO' int); > substr(char * 'FROM' int 'LENGTH' int); > > Interesting. That's one possible form, but it's not quite what I meant. What I meant is that you have a way to declare the function and syntax so that you actually can write SUBSTR str1 FROM pos1 TO end and the compiler knows what library to call in which way. This doesn't look too complicated, and it's not actually that different from SUBSTR_FROM_TO str1, pos1, end Just a slightly different syntax. > But you'd still need to be able to attach a boat load of attributes to > the function to give the compiler the same capabilities it would have > if these functions were actually built-in language constructs and the > compile times would be horrendous. I don't understand why. This doesn't seem to be much more complicated to parse than a normal function call. It's a starting token SUBSTR, followed by five tokens that have to be three expressions interspersed with FROM and TO. > I think it would be do-able but you'd still need some kind of meta > language to describe how these functions would interact with each > other, their parameters and local variables that are used with them > (from outside the call and not just as a parameter). I'm not sure what you mean by "interaction". The interaction of functions is defined by the language standard that defines what they do. Their arguments would be described just as they are in any procedural language. You'd need a bit of a meta language to define such a construct, but not much I think. I don't think this goes much further than a normal function declaration; just add to the " " pairs a possible pair "KEYWORD ". > An intrinsic function is one that the compiler understands intimately. > Not just what parameters it takes and what result it returns. Next step is to define what "understands intimately" means. Does a specification (like in a language standard) qualify? > In C++ you can actually write your own add ('+') operator function. Which would be different from the standard operator+() functions, in that the compiler doesn't "know" what they are supposed to be doing and has to treat them as normal function calls (in the case of C++ with the special rules that the language standard defines for operator+(), of course). >> Take any standardized language with a standardized library. For >> example, the C++ standard (the real one costs money, but here is a >> not quite up to date one ). >> And of course, anything that's missing /could/ be there -- it just >> isn't. >> >> Or C# (ECMA-336) and the .NET CLI (ECMA-335), even though that's >> possibly a bit different. > > Ok I've had a look on the net and it's just template stuff. As I've > said before, the compiler isn't really understanding intent here it's > just mechanically churning out code and reducing it as much as > possible. It gives the illusion that it understands what is going on > because so much source code is being condensed into a small > executable but the reallity is that all that source code is hand > holding the compiler and telling it exactly what to generate. Not sure whether the standard can tell you what kind of optimizations actual compilers implement. Much of this is probably a trade secret. Then I'm not convinced a casual look at this is enough to find out what /could/ be implemented. They don't talk about optimizations in the standard; they just say what has to be the result. Going back to one of your original arguments, the one that prompted my question about what the difference is between list operations that are implemented by the compiler and list operations that are implemented in a standard library: the substitution of a delete from a list followed by an insert into a list at the same location by a replace. If you want to implement such an optimization in your compiler, what's the difference between having these functions as part of the compiler, or having them defined as standard library functions in the standard that the compiler is based upon? In both cases, the compiler "knows" that this substitution is possible and the exact implementation of the three functions is not necessary to be known for this optimization to be possible. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist