General purpose Expression Parser

[jacob navia]

I suppose you know what templates are. If you do, I suppose you consider
having complex numbers and rest of area-specific stuff built in better
than having useful general purpose facilities built in.

Falconer is the resident troll.

Just ignore him

 

[Joe Wright]

Ioannis Vranos said:

CUSTOMER: "I'd like a knife and fork, please."
WAITER: "Here you are, sir."
CUSTOMER: "Wait a moment - this fork has no sharp edge."
WAITER: "That's right."
CUSTOMER: "But this knife has a lovely edge on it. Why can't the fork be
like that?"
WAITER: "Because it's a fork."
CUSTOMER: "This knife has serrations along the blade to improve its grip
during the cut. Why can't the fork have serrations?"
WAITER: "Because it's a fork. If you want to cut, use the knife."
CUSTOMER: "So what you're saying is that the fork is useless? I don't need
it?"
WAITER: "No, what I'm saying is that I don't get paid enough to deal with
people like you."

Priceless.

 

[Ioannis Vranos]

Ioannis Vranos said:

CUSTOMER: "I'd like a knife and fork, please."
WAITER: "Here you are, sir."
CUSTOMER: "Wait a moment - this fork has no sharp edge."
WAITER: "That's right."
CUSTOMER: "But this knife has a lovely edge on it. Why can't the fork be
like that?"
WAITER: "Because it's a fork."
CUSTOMER: "This knife has serrations along the blade to improve its grip
during the cut. Why can't the fork have serrations?"
WAITER: "Because it's a fork. If you want to cut, use the knife."
CUSTOMER: "So what you're saying is that the fork is useless? I don't need
it?"
WAITER: "No, what I'm saying is that I don't get paid enough to deal with
people like you."

This fictional conversation has nothing to do with the value of
function/struct templates in terms of *elegance (simplicity)*,
*efficiency*, *type safety* as a newer and better tool, replacing
generic functions currently implemented with void * and conditions, and
macros.


As an example of C++ features adoption, consider function-prototypes
adopted and provided in C89 as well as other features I do not remember now.

 

[CBFalconer]

.... snip ...

This fictional conversation has nothing to do with the value of
function/struct templates in terms of *elegance (simplicity)*,
*efficiency*, *type safety* as a newer and better tool, replacing
generic functions currently implemented with void * and conditions,
and macros.

As an example of C++ features adoption, consider function-prototypes
adopted and provided in C89 as well as other features I do not
remember now.

So? I think the point is that function/struct templates are a C++
feature, and discussion belongs in c.l.c++, not here. In c.l.c it
is off-topic.

 

[Anand Hariharan]

Ian Collins wrote: (...)

Nothing right now. However I think template functions and structs could
be introduced in C.

If you have a figured out a way to introduce templates in C without
breaking its linkage specification and without introducing horrible
kludges in its grammar, am sure you will find people interested in
listening to you.

- Anand

 

[santosh]

So? I think the point is that function/struct templates are a C++
feature, and discussion belongs in c.l.c++, not here. In c.l.c it
is off-topic.

If Ioannis is serious about the possibility of some type of generics in
future C then he could start a discussion in comp.std.c, where it would
be topical as a proposed extension, but he might need to think this out
far more rigorously is that case.

 

[user923005]

This fictional conversation has nothing to do with the value of
function/struct templates in terms of *elegance (simplicity)*,
*efficiency*, *type safety* as a newer and better tool, replacing
generic functions currently implemented with void * and conditions, and
macros.

As an example of C++ features adoption, consider function-prototypes
adopted and provided in C89 as well as other features I do not remember now.

I thought about this for a while. At first, I thought that templates
in C was a very good idea. They lead to simpler, easier to understand
and more generic versions of data structures and algorithms. And to
create templates, you would not need all the machinery of C++. But
then I started to see holes in it. For instance, because you do not
have operator overloading, you cannot extend the pretty version of
sorting algorithms which have a compare operator, since C strings
would not compare correctly. Also, things like a complex number
template that I suddendly want to reuse for extended precision are not
going to work properly either. So the templates are really going to
be crippled in C. When I thought about it long enough I finally
decided that I would never use them, because I would use C++ to write
the algorithms like that anyway. In short, I think that the idea is
great on the surface but when you think about it they would be clearly
inferior to C++ templates because we do not have operator overloading
and constructors and other things that make them work so nicely in C+
+.

 

[Morris Dovey]

An interview of the inventor of C++ templates, Alexander Stepanov, where
it mentions Java:

http://www.stlport.org/resources/StepanovUSA.html

An interesting link I came across the web:

http://icl.pku.edu.cn/bswen/_old_stuff/cpp/java-to-cpp.html

A slightly more general solution is a BNF (expanded to include
O/P capability) compiler. Source code for an early version is:

http://www.iedu.com/c/plc2.plc

This is version 2 of the program written in the source it
compiled.

 

[Ioannis Vranos]

I thought about this for a while. At first, I thought that templates
in C was a very good idea. They lead to simpler, easier to understand
and more generic versions of data structures and algorithms. And to
create templates, you would not need all the machinery of C++. But
then I started to see holes in it. For instance, because you do not
have operator overloading, you cannot extend the pretty version of
sorting algorithms which have a compare operator, since C strings
would not compare correctly. Also, things like a complex number
template that I suddendly want to reuse for extended precision are not
going to work properly either. So the templates are really going to
be crippled in C. When I thought about it long enough I finally
decided that I would never use them, because I would use C++ to write
the algorithms like that anyway. In short, I think that the idea is
great on the surface but when you think about it they would be clearly
inferior to C++ templates because we do not have operator overloading
and constructors and other things that make them work so nicely in C+
+.

Let's remove struct templates out for the moment. Regarding template
functions, function overloading is needed too, which is not a bad idea
for C to have too. I do not think any other C++ feature is needed for
this. Again, I have removed template structs out of the question.

 

[Ian Collins]

Let's remove struct templates out for the moment. Regarding template
functions, function overloading is needed too, which is not a bad idea
for C to have too. I do not think any other C++ feature is needed for
this. Again, I have removed template structs out of the question.

The correct terminology is "function template", which is what they are,
templates used to construct functions. The biggest issue with the
apparently simple addition of function overloading is the requirement
for standardised name mangling, which would break backwards
compatibility. Then there's all the matching rules to consider.

All this is best left where it belongs, in C++.

 

[jacob navia]

I thought about this for a while. At first, I thought that templates
in C was a very good idea. They lead to simpler, easier to understand
and more generic versions of data structures and algorithms. And to
create templates, you would not need all the machinery of C++. But
then I started to see holes in it. For instance, because you do not
have operator overloading, you cannot extend the pretty version of
sorting algorithms which have a compare operator, since C strings
would not compare correctly. Also, things like a complex number
template that I suddendly want to reuse for extended precision are not
going to work properly either. So the templates are really going to
be crippled in C. When I thought about it long enough I finally
decided that I would never use them, because I would use C++ to write
the algorithms like that anyway. In short, I think that the idea is
great on the surface but when you think about it they would be clearly
inferior to C++ templates because we do not have operator overloading
and constructors and other things that make them work so nicely in C+
+.

But then, why not compile time functions?

The basic idea of templates is to allow a function that
generates code at compile time.

In C++ the code generation is done by the compiler, and we have

1) The template definition time, where the compiler parses a
definition of a template and stores it away.
2) The template expansion time, when the template is used.
Here the compiler "expands" the template code, doing the
replacement of the given arguments within the template
text.

In lcc-win, you can define a compile time function, that
is, a function that will be called during the compilation,
and that can receive formal arguments. This function will
produce C code as output, just like a template, but with
fundamental differences:

A) You have the full C language for your code generation.
Within C++, you *can* trick the compiler to use IF ELSE
and other constructs, but it is very difficult, and purely
functional. You CAN'T save the state of the generation
or call subroutines, etc etc. You are very limited, and
code generation within templates suffers from this.

Compile time functions are EXECUTABLE code (i.e. already
compiled code) that have the full power of C to generate
code.

B) There are two ways to call a compile time function:

B.1: Direct: list<int>
B.2 Indirect: When an event fires. The compiler produces
a stream of events: function start, variable definition start,
statement end, statement start, block end, block start,
comment start, etc. You can the tell the compiler to call
your function when a specific event fires, in the same
way as aspect oriented programming does.

All this is working in prototype form. I wrote a full variant
of C with Betrand Meyer's programming by contract (require/ensure)
with it, and used the features that I needed to do that.

But I am completely alone doing this, and I got discouraged by the
negative attitude in this group. It is a pity because this is much
more powerful and interesting than C++.

The problem with C++ is that the compiler is too complex. This feature
allows to keep the compiler very simple and have MUCH MORE power at
your fingertips!

 

[Ian Collins]

But then, why not compile time functions?

I'd be interested in discussing this off-line, email my Usenet address
and I'll reply with my real one.

 

[jacob navia]

I'd be interested in discussing this off-line, email my Usenet address
and I'll reply with my real one.

My usenet address is below in my .sig

 

[Kenny McCormack]

If Ioannis is serious about the possibility of some type of generics in
future C then he could start a discussion in comp.std.c, where it would
be topical as a proposed extension, but he might need to think this out
far more rigorously is that case.

Wrong. You really need to check your catechism books more closely.

As noted earlier, csc is for nitpicking the standards document, not for
suggesting new stuff. I am not making this up.