sergio masci wrote: >> I resisted the temptation to quote all the stuff again... :) > > I felt it was necessary because several days have gone by between > your post and my response. Yes... no critique meant with my comment. It just was /a lot/ :) >>> You seem to be saying that provided a set of libraries are well >>> written and available in source form to the compiler that it can >>> compile these together with the user program and (given that the >>> compiler is implemented well enough by the compiler writers) that >>> the compiler should be able to extract enough information from all >>> the combined source code to generate a resulting executable that is >>> as good as one that would be generated if the language had more >>> built-in features such as STRING, LIST, DYNAMIC ARRAYS etc. >>> Furthermore that the compiler should be able to catch the same kind >>> of bugs in both cases. >> >> Not quite. Firstly, I was talking about /standard/ libraries, where >> the compiler also "knows" what the functions are supposed to do >> (because it's defined in the same place where is defined what the >> compiler itself is supposed to do). > > 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. >>> if strings were built into the language we might instead write: >>> >>> str = "hello world" + string(j) >> >> See, in C++ for example, strings are /not/ built into the language, >> and you can write pretty much exactly this. (Not with the >> std::string, but if you extend it a bit, you can, so in the case of >> C++ it's not really a question whether or not it can be done with >> strings in a library but whether the library definition is >> sufficient.) > > But the C++ compiler understands what is going on here even less. We > now end up adding even more run time overheads just to make the > source code look better. Not sure to what degree a compiler "understands", and I don't want to drift off in a discussion about the arbitrary shortcomings of C or C++. But when a compiler "knows" the intent of the line (because all operations that happen are defined in the language standard) and knows the implementation (because it of course "sees" the implementation of the operators that are implemented in the compiler, but it also sees the implementation of the library functions by making their sources available) -- what's the difference that's left between built-in and library? >> I agree that the lack of a built-in decent string type in C can be a >> pain, especially in terms of syntax. OTOH, I bet your strings are >> 8-bit strings. Now what if I need to handle Unicode strings? Wait >> for a compiler upgrade? And what if that compiler upgrade doesn't >> handle the Unicode encoding I need? > > Yes I understand your point of view, but 8-bit strings are still very > useful even if you need to use Unicode in the same program. Just like > integers are very useful even though you might need to use floating > point. 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. >> (Snipped prelude to substr argument.) >> >>> But this comes with it's won hazards, mainly that the user could VERY >>> easily write: >>> >>> str2 = substr(str1, pos1, len); >>> >>> where he actually needed: >>> >>> str2 = substr_lengeth(str1, pos1, len); >>> >>> Realistically how is a conventional compiler (one that is not mega >>> complex and running on an infinately fast build machine with an >>> infinate amount of RAM) going to spot this type of mistake without >>> adding a ton of attributes to the function prototype? >>> >>> If strings were built in we could simply say something like >>> >>> str2 = substr str1 from pos1 to pos2 >>> >>> or >>> >>> str2 = substr str1 from pos1 to end >>> >>> or >>> >>> str2 = substr str1 from pos1 length len >> >> This is a simple matter of syntax. You don't do much more here than >> comparing C-style syntax with BASIC-style syntax. A matter of >> taste... The BASIC-style syntax uses "substr ... from ... to" and >> "substr ... from ... length". A similar C-style syntax could use >> substr_from_to and substr_from_len -- or any number of similar >> variants. Then there's the LISP syntax, and a few others. I don't >> see what this has to do with built-in vs library. > > It makes a difference if you consider that each statement helps the > compiler understand what the perpose of a variable is. In the above > example 'length len' within the 'substr' statement allows the > compiler to understand that 'len' is being used to manipulate strings > in this fragment so it WOULD be able to help me catch a simple error > such as: > > for (j=0; j { > len2 = strlen(arr[j]); > > arr2[j] = substr(arr[j], 0, len-2); > } Be that as it may, but this is a difference between a specific C-style syntax and a specific BASIC-style syntax. There's nothing that would prevent a language to allow BASIC-style syntax for libraries (functions with several indentifiers that separate the arguments and together form one library call), so I don't really see the point WRT our discussion of built-in vs library. FWIW, my point was about specific function names. You didn't use my function names, so I don't know what you meant here. If you want to, can you rewrite this using substr_from_to and substr_from_len, then explain what is the difference to the BASIC variant? >>> I wonder if what you are really saying is that the compiler can do >>> more error checking and optimisation because it has all the source >>> rather than pre-compiled libraries? >> >> What I'm saying is that if it has the intent /and/ the source (the >> implementation), it can apply both for (usually different, and >> complementary) optimizations. Not that different from what it can do >> for built-in constructs. > > Ok, but you really are talking about intrinsics as I understand them > with the addition of a standard library function for each intrinsic. We probably need a common definition of "intrinsic function". I was talking about standard libraries that contain functions (and other language elements) that are defined in the language standard, in the same way as the language elements that the compiler implements. And additionally, to give the compiler access to the specific implementation (not only to the intent), the libraries are available to the compiler in source code. The intrinsic functions that are used e.g. in gcc and VC++ are not of this type. Most (if not all) are not even standard. >>> I talk about the brick wall between the compiler and the libraries >>> and you respond with "make the source of the libraries available". >> >> No. I say consider that the library is a /standard/ library. Adding >> the source code is in addition, so that the compiler not only >> "knows" the intent, but also sees the implementation. > > got you. intrinsic + library I'm not so sure... :) "Intrinsic" seems to imply (possibly among other things) that the library is written by the compiler vendor. I don't mean to imply this. >> Look at the C++ standard library definition for std::list::insert, >> for example. It contains a definition that allows each C++ compiler >> to "understand" what a call to std::list::insert is supposed to do. > > I will look at this. Can you point me at a specific doc and library > so that I can be sure to look at exactly what you are looking at. 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. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist