Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3744 > unrolled thread

Re: A tiny self-hosting compiler used for teaching

Back to article view | Back to comp.compilers

Contents

  Re: A tiny self-hosting compiler used for teaching Michael Lehn <michael.lehn@uni-ulm.de> - 2026-08-25 08:05 +0200
    Re: A tiny self-hosting compiler used for teaching Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-09-04 21:12 +0000
    Re: A tiny self-hosting compiler used for teaching ram@zedat.fu-berlin.de - 2026-09-05 07:02 +0000
      Re: A tiny self-hosting compiler used for teaching Michael Lehn <michael.lehn@uni-ulm.de> - 2026-09-05 19:47 -0700
    Re: A tiny self-hosting compiler used for teaching George Neuner <gneuner2@comcast.net> - 2026-09-05 14:02 -0400
      Re: A tiny self-hosting compiler used for teaching Michael Lehn <michael.lehn@uni-ulm.de> - 2026-09-05 19:50 -0700
    Re: A tiny self-hosting compiler used for teaching ram@zedat.fu-berlin.de - 2026-09-05 07:02 +0000
    Re: A tiny self-hosting compiler used for teaching George Neuner <gneuner2@comcast.net> - 2026-09-05 14:02 -0400
      Re: A tiny self-hosting compiler used for teaching George Neuner <gneuner2@comcast.net> - 2026-09-07 15:23 -0400
    Re: A tiny self-hosting compiler used for teaching Michael Lehn <michael.lehn@me.com> - 2026-09-05 22:58 -0700

#3744 — Re: A tiny self-hosting compiler used for teaching

Thanks! I was actually aware of the other ABC, but thought the name collision
would probably not matter for a small educational project. The name also grew
historically, and the wordplay was simply too tempting.

The compiler my students write in the course was originally called “A Bloody
Compiler”, hence ABC, and was written in C. Later I replaced C in the course
with a small language I called “A Better C”. So the students ended up writing
“A Bloody Compiler” in “A Better C”.

The main motivation for A Better C is actually quite mundane. When teaching C,
I always found declarations unnecessarily difficult to explain. For example:



    int *a[10];    // array of 10 pointers to int
    int (*b)[10];  // pointer to an array of 10 ints

There is a perfectly consistent logic behind C declarations: you declare an
object in a form resembling how it is used. But for beginners this means that
they already need to understand operator precedence — in particular that
postfix operators bind more strongly than prefix operators — just to read a
declaration.

I learned Pascal before C myself, and always found Pascal declarations easier
to read because you can essentially read them from left to right.

That is almost the whole idea behind A Better C: it is basically C, but with
declarations following a Pascal-like logic. Since `^` already has a meaning in
C, I used `->` for pointers.

Apart from the declarations, I deliberately kept the language very close to C,
because the subsequent HPC courses use C or C++. The idea is that once
students have learned the basic concepts in ABC, moving on to C should require
learning C's declaration syntax rather than learning another substantially
different language.

Interestingly, when I introduced ABC some years ago, several colleagues were
quite concerned about this. Their argument was that students without prior
programming experience would now have to learn _two_  languages instead of
one, making things even harder for them.

In practice, we have seen the opposite. Since introducing ABC, students who
come to the course without previous programming experience have had a
noticeably easier time. They can first learn the programming concepts without
having to deal with some of C's syntactic peculiarities, and the later
transition to C or C++ has not been a problem.

So “A Better C” is not meant as a grand claim that I fixed C. :-) It is really
just C adjusted a little for the way I found it easier to teach.


Michael Lehn

University of Ulm, Institute for Numerical Mathematics
Helmholtzstr. 20
D-89069 Ulm, Germany
Phone: (+49) 731 50-23534, Fax: (+49) 731 50-23548

[toc] | [next] | [standalone]

#3754

Congratulations on an FPGA implementation.

"Interestingly, there is usually another group of students as
well. Many of them already know me from previous mathematics courses
and are curious to see what a programming course taught by a
mathematician looks like."
says
HTTPS://Github.com/michael-lehn/not-abc/tree/main/hpc0-sessions/session00

"No previous programming experience is assumed.

Designing such a course is surprisingly similar to teaching first-year
mathematics."
says
HTTPS://Github.com/michael-lehn/not-abc/tree/main/hpc0-sessions

Michael Lehn <michael.lehn@Uni-Ulm.De> wrote:
|------------------------------------------------------------------------------|
|"[. . .]                                                                      |
|                                                                              |
|[. . .] When teaching C,                                                      |
|I always found declarations unnecessarily difficult to explain. [. . .]       |
|                                                                              |
|[. . .]                                                                       |
|                                                                              |
|[. . .]                                                                       |
|[. . .] But for beginners this means that                                     |
|they already need to understand operator precedence [. . .]                   |
|[. . .]                                                                       |
|                                                                              |
|[. . .]                                                                       |
|                                                                              |
|[. . .]                                                                       |
|[. . .] the subsequent HPC courses use C or C++. The idea is that once        |
|students have learned the basic concepts in ABC, moving on to C should require|
|learning C's declaration syntax rather than learning another substantially    |
|different language.                                                           |
|                                                                              |
|Interestingly, when I introduced ABC some years ago, several colleagues were  |
|quite concerned about this. Their argument was that students without prior    |
|programming experience would now have to learn _two_  languages instead of    |
|one, making things even harder for them.                                      |
|                                                                              |
|[. . .]"                                                                      |
|------------------------------------------------------------------------------|

Normally a compiler module is in the 4th year of a degree, so students
already used to have many "previous programming experience"s including
with C. So why are the ABC students ignorant of C (and even with no
"previous programming experience") at the start of this module? Are
they mathematicians or non-computer-scientists or
non-software-engineers?

HTTP://Gloucester.Insomnia247.NL/
explains an easy way to find a real email address for me.

[toc] | [prev] | [next] | [standalone]

#3755

Michael Lehn <michael.lehn@uni-ulm.de> wrote or quoted:
>In practice, we have seen the opposite. Since introducing ABC, students who
>come to the course without previous programming experience have had a
>noticeably easier time. They can first learn the programming concepts without
>having to deal with some of C's syntactic peculiarities, and the later
>transition to C or C++ has not been a problem.

  Writing a compiler requires implementing complex data structures
  (like symbol tables) and managing memory. If students have no prior
  programming experience, they must learn basic control flow, data
  structures, memory management and compiler theory simultaneously.
  This creates a steep learning curve, even with a simplified language.

  The claim that transitioning to C or C++ later "has not been a
  problem" is the most debatable point. While learning concepts
  first is beneficial, C requires a deep understanding of hardware
  interaction, manual memory management, and pointers - areas where
  students taught via idealized languages frequently struggle.
[What language to teach first is an old and insoluble problem.  When
I was in school most places started with Pascal while MIT started
with Lisp.  That meant they were dealing with interesting data
structures and introspection while we were still explaining how
big to make an array. -John]

[toc] | [prev] | [next] | [standalone]

#3759

> On 5. Sep 2026, at 17:17, ram@zedat.fu-berlin.de wrote:

> Michael Lehn <michael.lehn@uni-ulm.de> wrote or quoted:

>> In practice, we have seen the opposite. Since introducing ABC, students who
>> come to the course without previous programming experience have had a
>> noticeably easier time. They can first learn the programming concepts without
>> having to deal with some of C's syntactic peculiarities, and the later
>> transition to C or C++ has not been a problem.
>
>   Writing a compiler requires implementing complex data structures
>   (like symbol tables) and managing memory. If students have no prior
>   programming experience, they must learn basic control flow, data
>   structures, memory management and compiler theory simultaneously.
>   This creates a steep learning curve, even with a simplified language.
>
>   The claim that transitioning to C or C++ later "has not been a
>   problem" is the most debatable point. While learning concepts
>   first is beneficial, C requires a deep understanding of hardware
>   interaction, manual memory management, and pointers - areas where
>   students taught via idealized languages frequently struggle.
> [What language to teach first is an old and insoluble problem.  When
> I was in school most places started with Pascal while MIT started
> with Lisp.  That meant they were dealing with interesting data
> structures and introspection while we were still explaining how
> big to make an array. -John]
>



I think this assumes that students are asked to learn all these things at
once. That is not how the course is structured.

The compiler is developed incrementally over an entire semester. Students
begin with small ABC programs and basic experiments with control flow,
variables, and functions. Data structures, recursion, pointers, memory
management, parsing, and code generation are introduced step by step. Each
assignment contributes one small, reusable component. By the time the
components are assembled into a compiler, most of them have already been
implemented and understood separately.

Nor is ABC an idealized language that hides the machine. It deliberately
includes pointers, pointer arithmetic, recursive data structures, and manual
memory management with `malloc` and `free`. What it removes is mainly some of
C’s historical and syntactic complexity.

The course uses a flipped-classroom format: students prepare with short
English videos containing live programming, and the actual exercises are
completed in two-hour classroom sessions with individual assistance. No
previous programming experience is assumed.

The first English worksheets, lecturer notes, and links to the lecture videos
are available here:

https://github.com/michael-lehn/not-abc/tree/main/hpc0-sessions

So the statement about the transition to C and C++ is not a general
theoretical claim about first languages. It is an empirical observation from
several iterations of this particular course: the transition has not caused
the problems one might expect, while beginners have found the initial
introduction noticeably easier.

[toc] | [prev] | [next] | [standalone]

#3756

On Tue, 25 Aug 2026 08:05:06 +0200, Michael Lehn
<michael.lehn@uni-ulm.de> wrote:


>The main motivation for A Better C is actually quite mundane. When teaching C,
>I always found declarations unnecessarily difficult to explain. For example:
>
>    int *a[10];    // array of 10 pointers to int
>    int (*b)[10];  // pointer to an array of 10 ints
>
>There is a perfectly consistent logic behind C declarations: you declare an
>object in a form resembling how it is used. But for beginners this means that
>they already need to understand operator precedence — in particular that
>postfix operators bind more strongly than prefix operators — just to read a
>declaration.
>
>I learned Pascal before C myself, and always found Pascal declarations easier
>to read because you can essentially read them from left to right.


I also learned Pascal before C, and I always have preferred
Pascal-like syntax to the line noise that is typical of C.  Ironically
most of my career was spent using C++, SQL and Scheme.


IMO, the main reasons that Pascal declarations were easier are:

  1) variable names are not intermixed with their types

  2) complex types generally require one or more type declarations
     and can't be declared inline in a variable declaration

WRT your examples (and ignoring array base issues), in Pascal the
array of pointers is no problem /because/ the base type of the array
is simple, however the pointer to array can't be declared in one step
because the array itself is not a simple type.

  type
    tenInts = array [1..10] of integer;
  var
    a : array [1..10] of ^integer; { array of 10 pointers to int }
    b : ^tenInts;                  { pointer to array of 10 ints }


Yes, reading the declaration for 'b', you do have to go search out the
declaration of 'tenInts', but what you don't have to do is decipher a
string of line noise to understand the type.

Of course, in C you could typedef the array and declare 'b' as a
pointer to it - but most programmers would never think to do that with
such a "simple" declaration.  Few even would bother declaring 'b' a
"pointer to array of int" when "pointer to int" will work just as
well.
[ignoring potential for error checking by the compiler.]

And, of course, if you want a Pascal-like language with more
functional parity to C there were/are extended and OO Pascals, and
derivatives like Modula 2, 2+, 3, etc.


>That is almost the whole idea behind A Better C: it is basically C, but with
>declarations following a Pascal-like logic. Since `^` already has a meaning in
>C, I used `->` for pointers.

Yeah ... but what do the declarations look like?  Unless you totally
changed the syntax, just changing what token(s) denote a "pointer" or
a "dereference" operation is no more helpful than is the original C.

YMMV.

[toc] | [prev] | [next] | [standalone]

#3760

> On 5. Sep 2026, at 17:18, George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 25 Aug 2026 08:05:06 +0200, Michael Lehn
> <michael.lehn@uni-ulm.de> wrote:
>> The main motivation for A Better C is actually quite mundane. When teaching C,
>> I always found declarations unnecessarily difficult to explain. For example:

>>   int *a[10];    // array of 10 pointers to int

>>   int (*b)[10];  // pointer to an array of 10 ints
>

>> There is a perfectly consistent logic behind C declarations: you declare an
>> object in a form resembling how it is used. But for beginners this means that
>> they already need to understand operator precedence — in particular that
>> postfix operators bind more strongly than prefix operators — just to read a
>> declaration.

>> I learned Pascal before C myself, and always found Pascal declarations easier
>> to read because you can essentially read them from left to right.

> I also learned Pascal before C, and I always have preferred
> Pascal-like syntax to the line noise that is typical of C.  Ironically
> most of my career was spent using C++, SQL and Scheme.  ...



Yes, I did totally change the declaration syntax. That is the point. :-)

The two declarations look like this in ABC:


    a: array[10] of -> int;
    b: -> array[10] of int;


Thus, `a` is an array of ten pointers to integers, whereas `b` is a pointer to
an array of ten integers.

The variable name is separated from its type, and the type itself can be read
from left to right. `->` is a prefix type constructor, rather than merely a
replacement for `*` within C’s declaration syntax. No parentheses or knowledge
of expression-operator precedence are required to distinguish the two types.

The same principle also applies to more complicated types. For example:



    f: -> fn();
    g: -> fn(value: int);
    h: -> fn(value: int): int;


declare pointers to functions with increasingly detailed parameter and return
types.

ABC is not intended to suggest that Pascal, Modula-2, or related languages did
not already solve this problem. Quite the opposite: it deliberately preserves
their clearer declaration logic while retaining C-like expressions and a low-
level programming model.

[toc] | [prev] | [next] | [standalone]

#3757

Michael Lehn <michael.lehn@uni-ulm.de> wrote or quoted:
>In practice, we have seen the opposite. Since introducing ABC, students who
>come to the course without previous programming experience have had a
>noticeably easier time. They can first learn the programming concepts without
>having to deal with some of C's syntactic peculiarities, and the later
>transition to C or C++ has not been a problem.

  Writing a compiler requires implementing complex data structures
  (like symbol tables) and managing memory. If students have no prior
  programming experience, they must learn basic control flow, data
  structures, memory management and compiler theory simultaneously.
  This creates a steep learning curve, even with a simplified language.

  The claim that transitioning to C or C++ later "has not been a
  problem" is the most debatable point. While learning concepts
  first is beneficial, C requires a deep understanding of hardware
  interaction, manual memory management, and pointers - areas where
  students taught via idealized languages frequently struggle.

From: ram@zedat.fu-berlin.de (Stefan Ram)

[toc] | [prev] | [next] | [standalone]

#3758

On Tue, 25 Aug 2026 08:05:06 +0200, Michael Lehn
<michael.lehn@uni-ulm.de> wrote:


>The main motivation for A Better C is actually quite mundane. When teaching C,
>I always found declarations unnecessarily difficult to explain. For example:
>
>    int *a[10];    // array of 10 pointers to int
>    int (*b)[10];  // pointer to an array of 10 ints
>
>There is a perfectly consistent logic behind C declarations: you declare an
>object in a form resembling how it is used. But for beginners this means that
>they already need to understand operator precedence — in particular that
>postfix operators bind more strongly than prefix operators — just to read a
>declaration.
>
>I learned Pascal before C myself, and always found Pascal declarations easier
>to read because you can essentially read them from left to right.


I also learned Pascal before C, and I always have preferred
Pascal-like syntax to the line noise that is typical of C.  Ironically
most of my career was spent using C++, SQL and Scheme.


IMO, the main reasons that Pascal declarations were easier are:

  1) variable names are not intermixed with their types

  2) complex types generally require one or more type declarations
     and can't be declared inline in a variable declaration

WRT your examples (and ignoring array base issues), in Pascal the
array of pointers is no problem /because/ the base type of the array
is simple, however the pointer to array can't be declared in one step
because the array itself is not a simple type.

  type
    tenInts = array [1..10] of integer;
  var
    a : array [1..10] of ^integer; { array of 10 pointers to int }
    b : ^tenInts;                  { pointer to array of 10 ints }


Yes, reading the declaration for 'b', you do have to go search out the
declaration of 'tenInts', but what you don't have to do is decipher a
string of line noise to understand the type.

Of course, in C you could typedef the array and declare 'b' as a
pointer to it - but most programmers would never think to do that with
such a "simple" declaration.  Few even would bother declaring 'b' a
"pointer to array of int" when "pointer to int" will work just as
well.
[ignoring potential for error checking by the compiler.]

And, of course, if you want a Pascal-like language with more
functional parity to C there were/are extended and OO Pascals, and
derivatives like Modula 2, 2+, 3, etc.


>That is almost the whole idea behind A Better C: it is basically C, but with
>declarations following a Pascal-like logic. Since `^` already has a meaning in
>C, I used `->` for pointers.

Yeah ... but what do the declarations look like?  Unless you totally
changed the syntax, just changing what token(s) denote a "pointer" or
a "dereference" operation is no more helpful than is the original C.

YMMV.
[Your moderator has only limited sympathy for arguments about the aesthetics of
declarations, noting a strong pattern of people liking what they learned first.
Personally, I think Fortran EQUIVALENCE and COMMON statements are totally
intuituitive, but then I would. -John]

[toc] | [prev] | [next] | [standalone]

#3761

Hi John,

>[Your moderator has only limited sympathy for arguments about the aesthetics of
>declarations, noting a strong pattern of people liking what they learned first.
>Personally, I think Fortran EQUIVALENCE and COMMON statements are totally
>intuituitive, but then I would. -John]

Understood.

It was meant more to be a question of what was being done in the
author's language.  I thought it needed a bit of background -
apologies if that went too far astray.

George

[toc] | [prev] | [next] | [standalone]

#3763

Yes, exactly. They are not computer science students, and HPC0 is not a
conventional compiler course.

I teach at the Institute of Numerical Mathematics. The students come mostly
from mathematics and related programs, and their programming experience varies
considerably. Some have programmed before, while others have essentially no
experience at all. Therefore I deliberately assume none.

The compiler is not really the subject of the course. It is a vehicle for
teaching programming and for connecting the different levels of a computer
system.

The idea is to start with a very small language and gradually follow the whole
path from a source program down to the machine:



    source program -> compiler -> assembly -> processor

In parallel, we approach the same machine from the other direction, starting
with logic gates and building a small processor. Eventually the two paths
meet.

So in that sense it is almost the opposite of a traditional fourth-year
compiler course. I am using compiler construction as an introduction to
programming and computer systems rather than teaching compiler construction as
an advanced specialization.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web