Stroustrup "desk calculator" chapter 6

[arnuld]

Stroustrup starts chapter 6 with a programme for desk-calculator:

here is a grammer for the langugae accepted by the calcualtor:

program:
END // END is end-of-input
expr_list END
expr_list:
expression PRINT // PRINT is semicolon
expression PRINT expr_list
expression:
expression + term
expression - term
term
.................................................
.................................................

what the heck it is?

 

[Thomas Tutone]

Stroustrup starts chapter 6 with a programme for desk-calculator:

here is a grammer for the langugae accepted by the calcualtor:

program:
END // END is end-of-input
expr_list END
expr_list:
expression PRINT // PRINT is semicolon
expression PRINT expr_list
expression:
expression + term
expression - term
term
................................................
................................................

what the heck it is?

It's the grammar for the language to be accepted by the calculator, the
program for which appears in the pages following the one you're looking
at.

Best regards,

Tom

 

[arnuld]

It's the grammar for the language to be accepted by the calculator, the

program for which appears in the pages following the one you're looking
at.

i know. i have seen the code but that code does not mean anything like
the DC programme (DC == desk calculcator).

why he started "expr_list:" after he did "expr_list END" on previous
line?
( he ended the list first & then started it)

 

[arnuld]

does Stroustrup say this:

C++ programme -> DC programme ( DC == Desk Calculator)

i mean, we will write a programme that will generate DC programme & we
will assum that will compute results (rather than computing results
directly with C++).

am i right?

 

[Renato Golin]

i know. i have seen the code but that code does not mean anything like
the DC programme (DC == desk calculcator).

why he started "expr_list:" after he did "expr_list END" on previous
line?
( he ended the list first & then started it)

The grammar only says what's accepted after a token, that's it. It's
only saying that you can have a "expr_list" after "program" but it have
to END there. Than, later, it says what have to be after "expr_list",
that's all.

You should implement your parser following those rules, that's all.

--renato

 

[Marcus Kwok]

Stroustrup starts chapter 6 with a programme for desk-calculator:

here is a grammer for the langugae accepted by the calcualtor:

program:
END // END is end-of-input
expr_list END
expr_list:
expression PRINT // PRINT is semicolon
expression PRINT expr_list
expression:
expression + term
expression - term
term
................................................
................................................

what the heck it is?

It is describing the format of what the calculator will accept. Your
calculator will take in a program.

A program is either empty (all it has is END), or it is an expr_list
followed by END.

An expr_list is an expression followed by PRINT (semicolon), or it is an
expression followed by PRINT followed by another expr_list.

An expression is either an expression followed by + followed by a term,
or an expression followed by - followed by a term, or just a term.

As you can see, these kinds of grammars tend to be very recursive in
nature.

The syntax is a little different, but maybe this explanation will be
enlightening:
http://en.wikipedia.org/wiki/Backus-Naur_form

 

[Kaz Kylheku]

i know. i have seen the code but that code does not mean anything like
the DC programme (DC == desk calculcator).

The dc program you find on some Unix systems uses reverse polish
notation.

This textbook program uses infix, and can only add and subtract.

why he started "expr_list:" after he did "expr_list END" on previous
line?

Let's see:

program:
END // END is end-of-input
expr_list END

The above grammar production rule means that a program is one of two
things. Either the symbol END, or an expr_list followed by the symbol
END. In other words, a program is an optional expression list followed
by an indication of the end of input.

expr_list:
expression PRINT // PRINT is semicolon
expression PRINT expr_list

This definition further specifies what an expression list is. Without
this definition, the production rule for "program" is incomplete.

Stroustrup is using the convention that names in ALL CAPS are terminal
symbols: symbols which do not name phrase structure rules, but
represent atoms in the input.

Lower case names are names of grammar production rules.

Another convention he's using is that there is an implicit "or" between
the lines of the production. Each line of the production rule is an
alternate production. So an expr_list is either an expression followed
by PRINT, or an expression followed by PRINT followed by another
expr_list.

He makes the note that PRINT is semicolon. That is to say, the the
abstract PRINT token is supposed to be produced when a semicolon
character is read from the input.

 

[arnuld]

It is describing the format of what the calculator will accept. Your
calculator will take in a program.

A program is either empty (all it has is END), or it is an expr_list
followed by END.

An expr_list is an expression followed by PRINT (semicolon), or it is an
expression followed by PRINT followed by another expr_list.

An expression is either an expression followed by + followed by a term,
or an expression followed by - followed by a term, or just a term.

As you can see, these kinds of grammars tend to be very recursive in
nature.
thanks.

The syntax is a little different, but maybe this explanation will be
enlightening:
http://en.wikipedia.org/wiki/Backus-Naur_form

yes, it helped a lot to understand the desk calculator.

 

[arnuld]

The above grammar production rule means that a program is one of two
things. Either the symbol END, or an expr_list followed by the symbol
END. In other words, a program is an optional expression list followed
by an indication of the end of input.
ok


He makes the note that PRINT is semicolon. That is to say, the the
abstract PRINT token is supposed to be produced when a semicolon
character is read from the input.

this is what i said: our job is to produce a C++ programme that will
output DC notation, rather than computing results directly with C++.
right?

 

[Alf P. Steinbach]

* arnuld:

this is what i said: our job is to produce a C++ programme that will
output DC notation, rather than computing results directly with C++.
right?

You have it backwards. The C++ program is to analyze a calculator
"program" text, as a specification of what it should do, and then either
produce the numerical result (acting as an interpreter) or some
intermediate form of the specification (acting as a compiler) that's
easier and more efficient to evaluate. Anyway it will probably involve
recursive functions, that is, functions calling themselves, which is
then probably much of the point.

Personally I like much better to use L-systems to introduce the power of
recursive functions, creating "interesting" graphics, but then Bjarne
can't assume availability of any graphics package in that book.

And parsing is very much AT&T Bell Labs stuff...

 

[arnuld]

You have it backwards. The C++ program is to analyze a calculator
"program" text, as a specification of what it should do, and then either
produce the numerical result (acting as an interpreter) or some
intermediate form of the specification (acting as a compiler) that's
easier and more efficient to evaluate. Anyway it will probably involve
recursive functions, that is, functions calling themselves, which is
then probably much of the point.

Personally I like much better to use L-systems to introduce the power of
recursive functions, creating "interesting" graphics, but then Bjarne
can't assume availability of any graphics package in that book.

And parsing is very much AT&T Bell Labs stuff...

is it really necessary to understand DC programme to understand rest of
the book? it is too complex for me to understand it. can i leave this
& go directly to section 6.2 without much loss?

 

[Alf P. Steinbach]

* arnuld:

is it really necessary to understand DC programme to understand rest of
the book?

I don't think so, because I don't recall the book mentioning any program
called "DC".

 

[arnuld]

I don't think so, because I don't recall the book mentioning any program
called "DC".

ok, ok here is the complete thing:

is it really necessary to understand "Desk Calculator programme" in
chapter 6 to understand rest of
the book?

it is too complex for me to understand it. can i leave this section
(6.1) of Desk Calculatro and go directly to section 6.2 without much
loss?

 

[Alf P. Steinbach]

* arnuld:

ok, ok here is the complete thing:

is it really necessary to understand "Desk Calculator programme" in
chapter 6 to understand rest of
the book?

it is too complex for me to understand it. can i leave this section
(6.1) of Desk Calculatro and go directly to section 6.2 without much
loss?

What's the exact first /word/ in that text where it starts sounding
difficult?

 

[Alf P. Steinbach]

* Alf P. Steinbach:

* arnuld:

What's the exact first /word/ in that text where it starts sounding
difficult?

Sorry, I'm beginning to see your problem.

I learned C++ from the first edition of TCPPPL, which was clear and
short and sweet, being based on K&R TCPL. Comparing it to the second
edition (someone got away with "borrowing" and never returning the third
edition, so I don't have it), which is four to five times heavier (in
weight) and much less readable: The very clear & short language overview
at the start of the first edition has been replaced with /long/ sections
of nothing particularly useful to know, in the second edition.

And without the clear language overview first, the desktop calculator
program may be difficult to grok; I mean, in the second edition not even
the 'for' loop has been explained at this point, not that 'for' loops
are explained later on either, except in the reference section. It was
of course properly explained in the first edition...

I therefore suggest looking up things in the reference section at the
back of the book.

That reference section is a very very positive feature of the book, and
before the standard of 1998 it served as a kind of de facto standard
(together with the Annotated Reference Manual book, the "ARM", now not
particularly useful).

Another reason why the program can be hard to understand is that it's
presented one small piece at a time, has some unreadable names, and uses
raw arrays and pointers and such.

So for your & others' convenience I've placed a version that has
(hopefully) more readable names, no pointer or raw array usage for most
of the code, and is in one single file, at <url:
http://home.no.net/alfps/misc/dc.cpp>.