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

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

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

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

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?

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


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


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


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

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

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

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

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