On Wed, 15 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
> 
> > Ok I've read and re-read your posts trying to understand what it is
> > that you are trying to say in order to better understand how I am
> > failing to get my point across.
> 
> 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.

> 
> > 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.

> 
> > As an example lets just consider how many different ways you can
> > append a number (as a string) to another string:
> 
> Secondly, this was (in my mind, at least) a discussion /only/ about the
> merits of features built-in (to the compiler) versus implemented in a
> (standard) library. This is not a discussion about the shortcomings of C
> (or about whether or not XSCB is better than C :).

Yes I agree this discussion is only about the merits of built-in features 
versus library functions. I do use examples written in C because many 
people on this list can relate to them and C uses library functions 
extensively to overcome its shortcomings.

> 
> So I snipped the following... all examples of how something can be done
> in C. Whether something is possible or not in C isn't really relevant to
> our discussion, I think.
> 
> > 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.

> 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.

Anyway having built-in features doesn't stop you adding sets of functions 
as libraries.

> > And we even got rid of the huge printf library as a side effect.
> 
> If that's a concern, HiTech for example parses all printf strings in the
> whole application and based on that decides what to include into printf.
> Since printf is a /standard/ library function, they can do this -- and I
> still can override theirs with mine, or make theirs work with my own
> putch function. I don't know how exactly they do it, but it doesn't
> really matter whether they have a bunch of configuration parameters for
> a printf library function and the compiler sets the configuration
> parameters accordingly, or whether their printf function is implemented
> in the compiler itself. It doesn't matter because it's a standard
> library, and as long as their compiler behaves accordingly (and lets me
> override their function with my own if I want), it's all fine.
> 

GCC allows you to add an attribute to a function so that the compiler will 
check the type of an actual parameter against a format string.

> 
> > A user would still rather write a couple of lines of code than waste
> > time looking up a trivial function in an over inflated library. You
> > need to give the user a real incentive to use this new library
> > function. On the other hand if this fragment of functionality is
> > built into the language (and compiler) and is itself a sub-set of a
> > basic component (feature) of the language (e.g. string handling) then
> > the user will embrace it sooner or later because he/she will be
> > constantly exposed to this feature and gradually progress from using
> > basic parts of this feature to the more complex aspects of it.
> 
> It's the number of symbols and their structure that makes a feature set
> "over inflated". IMO it doesn't make a difference whether you have 5000
> symbols in a library and people think it's too much or whether you have
> 5000 symbols in a compiler and people think it's too much. 
> 

Agreed.

> 
> (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<len; j++)
	{
		len2 = strlen(arr[j]);

		arr2[j] = substr(arr[j], 0, len-2);
	}

> 
> > I keep talking about the compiler understanding the intent of the
> > programmer and you keep saying that a compiler could do this if it
> > had all the source available. 
> 
> Nope, I never said that. I said that if we are talking about /standard/
> libraries, the compiler "knows" the intent of the /standard/ library
> functions just as well as it knows the intent of the built-in
> constructs; both are defined in the same standard. 

Ok I missinterpreted what you said - sorry :)

> 
> > 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.

> 
> > This (recognising intent) is easy to do if the language has an
> > understanding of common basic types such as strings, lists etc but
> > increadibly hard to do if it does not.
> 
> You seem to miss the point that the /intent/ of the functions in
> standard libraries is just as defined as the intent of language
> constructs built into the compiler. 

I understand what you mean by this now.

> 
> 
> > 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

> 
> > How for example would the compiler recognise a function whose purpose
> > it is to seach a list for a particular string and if it does not
> > exist then insert a copy of the string into the list in alphabetic
> > order?
> 
> Because this intent is defined in the standard.
> 
> 
> > Look at a small fragment for inserting an item into a list:
> > 
> > [snipped C code]
> > 
> > Now try writing a rule that understands the above two small
> > fragments as two identical units.
> 
> 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.

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist