Re: Top 10 most common hard skills listed on resumes...

Bart <bc@freeuk.com> wrote:

On 08/09/2024 01:05, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

 

Then you no longer have a language which can be implemented in a few KB.
You might as well use a real with with proper data types, and not have
the stack exposed in the language. Forth code can be very cryptic
because of that.

 
First, it is not my goal to advocate for Forth use.

 
You're doing a fine job of it!
 
For me it's one of those languages, like Brainf*ck, which is trivial to
implement (I've done both), but next to impossible to code in.

I wonder if you really implemented Forth.  Did you implement immediate
words? POSTPONE?

With Forth, I had to look for sample programs to try out, and discovered
that Forth was really a myriad different dialects. It's more of a DIY
language that you make up as you go along.

Well, there is the standard and several implementations that do not
follow the standard.  As in each language implementations have their
peculiar extentions.  And Forth is extensible, so there are user
extentions.

 

: 2*3 =>
** 6
: 2, 3, *() =>
** 6
the first line is infix form, '=>' oprator prints what is on
the stack (but you cat treat it as "print current result").
In the second line two numbers are pushed on the stack and
then there is call to multiplication routine.  Parser knows
that '*' is an operator, but since there are no argument
'*' is treated as ordinary identifer and as result you
get multiplication routine.  Like in other languages parentheses
mean function call.  Up to now this may look just as some
weirdness with no purpose.  But there are advantages.  One
is that Pop11 functions can return multiple values, they just
put as many values as needed on the stack.  Second, one can
write functions which take variable number of arguments.
And one can use say a loop to put varible number of arguments
on the stack and then call a routine expecting variable
number of arguments.  In fact, there is common Pop11 idiom
to handle aggregas: 'explode' puts all members of the aggregate
on the stack.  There are also constructor function which build
aggregates from values on the stack.

 
This sounds like one of my bytecode languages.
 
So, in the same way that Lisp looks like the output of an AST dump,
these stack languages look like intermediate code:
 
 
  HLL ->    AST     ->  Stack IL  ->  Interpret or -> ASM
  (eg. C)   (Lisp)      (Forth)
                        (Pop-11)

Well, in Pop11 it it more like

       reader           parser
   HLL   -> token stream -> Stack IL -> ASM or machine code in memory

Both reader (responsible for turning characters into tokens) and
parser are user extensible.  For example, general addition is defined
as:

define 5 x + y;
    lvars x, y;
    if isinteger(x) and isinteger(y) then
        if _padd_testovf(x, y) then return() else -> endif
    endif;
    Arith_2(x, y, OP_+)
enddefine;

The '5' after 'define' means that we are defining an operator which
have priority 5.  'lvars' says that 'x' and 'y' obey lexical
scoping (one could use 'vars' to get dynamic scope instead).
The 'isinteger' test check for machine-sized integers, if both
'x' aand 'y' are integers this takes fast path and uses machine
addition (with check for overfolw).  In case of no overflow the
result of machine addition is return.  Otherwise 'Arith_2' handles
(hairy) general cases.  Users can define their own operators.
For example

define 7 x foo y; y; enddefine;

defines operator 'foo' (of higher priority than addition).  And
we can use it:
: 1 foo 2 =>
** 2
: 2 + 3 foo 4 =>
** 4
: 2 + (3 foo 4) =>
** 6

Naive Fibonacci routine may look like this:

define fibr(n);
    if n < 2 then 1 else fibr(n - 1) + fibr(n - 2) endif
enddefine;

Note that use of the stack is invisible above, user may treat this
as something like Pascal, only that source language structures
must be terminated by verbose 'endif' and 'enddefine' respectively.
OTOH there is no need for explicit return, last value computed is
the return value.

There are some anomalies, assignment is written as:

a -> b;

which means assign a to b.  There is 'printf' which works
like this:

: printf(2, '%p\n'); 
2
: printf(2, 3, '%p %p\n');
3 2

Note that order of printed values is reversed compared to source
and format comes last, this is due to stack semantics.  You
can write things like:

external declare tse in oldc;

void
tse1(da, ia, sa, dp, ip, sp, d, i, s)
    double da[];
    int ia[];
    float sa[];
    double * dp;
    int * ip;
    float * sp;
    double d;
    int i;
    float s;
{
}

endexternal;

The first line switches on syntax extention and lines after that
up to 'endexternal' are parsed as C code.  More procisely, 'oldc'
expects KR style function definitions (with empty body).  As
result this piece of code generates Pop11 wrapper that call
corresponding C routine passing it arguments of types specified
in C definition (but on Pop11 side 'double da[]' and 'double * dp'
are treated differently).  Note that this in _not_ a feature of
core Pop11 langrage.  Rather it is handled by library code (which
in principle could by written by ordinary user.

Most people prefer to code in a HLL.

You mean "most people prefer by now traditional syntax", sure.

But this at least shows Lisp as
being higher level than Forth, and it's a language that can also be
bootstrapped from a tiny implementation.

Pop11 has very similar semantics to Lisp and resonably traditional
syntax.  I would say that Lisp users value more extensibility than
traditional syntax.  Namely Lisp macros give powerful extensibility
and they work naturaly with prefix syntax.  In particular, to do
an extension you specify tree transformation, that is transformation
of Lisp "lists", which can be done conveniently in Lisp.  In Pop11
extentions usually involve some hooks into parser and one need to
think how parsing work.  And one needs to generate representation
at lower level.  So extending Pop11 usualy is more work than extending
Lisp.  I also use a language called Boot, you will not like it
because it uses whitespace to denote blocks.  Semantics of Boot is
essentially the same as Lisp and systax (expect for whitespace)
is Algol-like.  A sample is:

dbShowConsKinds(page, cAlist) ==
  cats := doms := paks := defs := nil
  for x in cAlist repeat
    op := CAAR x
    kind := dbConstructorKind op
    kind  = 'category => cats := [x,:cats]
    kind = 'domain    => doms := [x,:doms]
    kind = 'package   => paks := [x,:paks]
    defs := [x,:defs]
  lists := [NREVERSE cats,NREVERSE doms,NREVERSE paks,NREVERSE defs]

If one really dislikes whitespace based syntax it would be not hard
to modify translator to produce more traditional syntax:

dbShowConsKinds(page, cAlist) == {
    cats := doms := paks := defs := nil;
    for x in cAlist repeat {
        op := CAAR(x);
        kind := dbConstructorKind(op);
        kind = 'category  => cats := [x, :cats];
        kind = 'domain    => doms := [x, :doms];
        kind = 'package   => paks := [x, :paks];
        defs := [x, :defs]
    }
    lists := [NREVERSE(cats), NREVERSE(doms), NREVERSE(paks), NREVERSE(defs)]
}

Some explanantion "for x in cList" indicates iteration over a list.
Boot allows to call single argument functions without parenthesis around
argument, in the second version I added parentheses for clarity.
':=' is assigment operator, '=' is equality, assignenet has a value
like in C.  '=>' is condition exit from a block.  That is if condition
on left hand side of it is true, then expression on the right hand side
is evaluated and rest of the block is skipped.  In Boot all expression
have value, in case of taken exit value of expression on the right
hand side is value of the block.  If no exit is teken, then value
of a block is value of last expression in the block.  Conditionals
have obvious value, value of a loop is Lisp 'nil'.

Construct like

[x, :cats]

builds a list, ':' means that 'cats' must be a list and is inserted
in this place.  So the result is prepending 'x' to 'cats'.
Again, body of a function is an expression and value produced
by this expression is returned from the function.

Drawback of Boot is that some Lisp constructs need awkward syntax
to access.  And that includes defining extentions, so extentions
are frequently done by defining macros at Lisp level (or your
way, by modifing translator).

Coming back to Forth, you can easily add infix syntax to Forth
but Forth users somewhat dislike idea of using infix for most
of programming.  My personal opinion is that Fort was good
around 1980.  At that time there was quite simple implementation,
language offered interactive developement and some powerful
feature and there were interesting compromise between speed
and size.

 
Around that time I was working on several languages that were low level
and with small implementations, which included running directly on 8-bit
hardware. They all looked like proper HLLS, if crude and simple.
 
There was no need to go 'weird'. For lower level, I used assembly, where
you weren't constrained to a stack.

Well, I had 48KB ZX Spectrum.  On it I could run Hisoft Pascal,
Hisoft C, FIG-Forth and other things.  At that time I had some
knowledge of C but really did not understand it.  Hisoft C gave
me similar speed to Hisoft Pascal, had less features (C lacked
floating point) and needed more memory.  FIG-Forth needed very
little memory but execution speed was significantly worse than
Pascal.  And my programs were small.  Some my programs needed
enough momory for data, but one could write a compiled progam
to the tape and run it from the tape.  So I mostly used Pascal.
But that could be different with less memory (compiler would
not run on 16kB Spectrum, FIG-Forth would be happy on it) or
with bigger programs.

I was not scared of "weird".  Rather, I had read Pascal books, could
define data structure and I general I had resonable idea
how to solve problem using Pascal.  About Forth in had less
info.  And for simple probles Forth did not look hard, just
somewhat more tedious.  So for me using Forth looked like
spending effort with no clear gain.

What started the subthread was the question of which HLL goes between
ASM and C (since someone suggested that C was mid-level).

 
Well, for me important question is how much work is due to tools
(basically overhead) and how much deals with problem domain.
Since computers are now much heaper compared to human work
there is desire to reduce tool overhead as much as possible.
This favours higher level languages, so probably most recently
created languages is at higher level than C.  However, in
sixties and seventies there were pack of so called algorithmic
languages or somewhat more specifically Algol family.  I would
say that C is close to the middle of this pack.

 
My exposure before I first looked at C was to Algol, Pascal, Fortran
(and COBOL).
 
C struck me as crude, and I would have placed it lower than FORTRAN IV,
even though the latter had no structured statements. But that was
because it exposed less in the language - you couldn't play around with
variable addresses for example. So FORTRAN was no good for systems
programming.

One of my early program did recursive walk on a graph.  Goal was
to do some circuit computation.  I did it in Basic on ZX 81.
I used GOSUB to do recursive calls, but had to simulate the argument
stack with arrays.  This led to severl compilcations, purely
because of inadequacy of the language.  Official Fortran without
recursion probably would be equally bad.  In Pascal or C the program
would be natrual and much simpler.  One point being recursion,
the other structures, in Basic or Fortran I had to emulate structures
using parallel arrays, in C and Pascal they were buit-in.

BTW: I would very much profer to use Pascal for the above, but
Basic was the only thing available to me on ZX 81.

 As a devils
advocate let me compare typical implementation of early Pascal

...

of early languages were at lower level than Pascal.

 
You're taking all those, to me, chaotic features of C as being superior
to Pascal.
 
Like being able define anonymous structs always anywhere, or allowing
multiple declarations of the same module-level variables and functions.

Look at this C code:

void
do_bgi_add(unsigned int * dst, int xlen, unsigned int * xp,
     int ylen, unsigned int * yp) {
    if (ylen < xlen) {
        int tmp = xlen;
        xlen = ylen;
        ylen = tmp;
        unsigned int * tmpp = xp;
        xp = yp;
        yp = tmpp;
    }
    unsigned int xext = (unsigned int)(((int)(xp[xlen - 1])) >> 31);
    unsigned int yext = (unsigned int)(((int)(yp[ylen - 1])) >> 31);
    unsigned int c = 0;
    int i = 0;
    while(i < xlen) {
        unsigned long long pp = (unsigned long long)(xp[i])
                              + (unsigned long long)(yp[i])
                              + (unsigned long long)c;
        dst[i] = pp;
        c = (pp >> (32ULL));
        i++;
    }
    while(i < ylen) {
        unsigned long long pp = (unsigned long long)xext
                              + (unsigned long long)(yp[i])
                              + (unsigned long long)c;
        dst[i] = pp;
        c = (pp >> (32ULL));
        i++;
    }
    {
        unsigned long long pp = (unsigned long long)xext
                              + (unsigned long long)yext
                              + (unsigned long long)c;
        dst[i] = pp;
    }
}


I claim that is is better than what could be done in early Pascal.
Temporary variables are declared exactly in scopes where they are
needed, I reuse the same name for 'pp' but scoping makes clear
that different 'pp' are different variables.  All variables
are initialised at declaration time with sensible values.  Only
parameters, 'i' and 'c' are common to various stages, they have
to.  Note that 'xext' and 'yext' are declared at point where I
can compute initial value.  Also note that among ordinary
variables only 'i' and 'c' are reassigned (I need to swap parameters
to simplify logic and 'dst' array entries are assigned as part of
function contract).  Fact that variables are not reassigned could
be made clearer by declaring them as 'const'.

Pascal was a teaching language and some thought went into its structure
(unlike C).

In general I like Pascal.  But in some areas Wirth had too rigid
view.  And experience changed notion of good program structure.

In my hands I would have given it some tweaks to make it a
viable systems language. For a better evolution of Pascal, forget Wirth,
look at Ada, even thought that is not my thing because it is too strict
for my style.

For system programming Turbo Pascal had what is needed.  For better
evolution look at Extended Pascal and GNU Pascal.  Extended Pascal
added variable initialization and relaxed constraints on declaration
placement.  Schema types give nice handling of variable length arrays.
GNU Pascal relaxed this a bit some remaining restrictions in Extended Pascal
and added system extentions (in particular Turbo Pascal is a subset of
GNU Pascal).

People suggested ones like BLISS and Forth.
>
I remarked that a proper HLL would let you write just A to either read
the value of variable A, or write to it. Eg. A = A, without special
operators to dereference A's address.

 
You are looking at superficial things.

 
Syntax IS superficial! But it's pretty important otherwise we'd be
programming in binary machine code, or lambda calculus.

Well, even in context of systax dot required by Bliss is little thing,
just a bit of mandatory noise.  When some dirt falls onto program listing
do you think that program is faulty because of this?

Concerning Forth and Lisp, some people like such syntax and there are
gains.

I am not going to write substantial programs in Bliss or Forth
but I have no double they are HLL-s.

 
So, what would a non-HLL look like to you that is not actual assembly?

In first approximation HLL = not(assembly).  Of course (binary, octal,
etc) machine language counts as assembly for purpose of this equation.
And some language like PL360 or Randall Hyde HLA which have constructs
which does not look like assembly still count as assembly.  Similarly
macro assemblers like IBM HLA count as assembly.  Fact that there is
a complier that turns IBM HLA Javascript, so that you can run it on
wide range of machines does not change this.  For me what count is
thinking and intent: using IBM HLA you still need to think in term
of machine instructions.  One can use macro assemblers to provide
set of macros such that user of those macros does not need to think
about machine instructions.  IIUC one of PL/I compilers was created
by using a macro assembler to implement a small subset of PL/I, and
then proper PL/I compiler was written in this subset.  But this
is really using macro assembler to implement different language.
In other words, once extentions can function as independent language
and users are encouraged to think in terms of new language,
this is no longer assembler, but a new thing.

Just as an extra explanantion, I read HLL as Higher Level Language,
with Higher implitely referencing assembly.  So it does not need
to be very high level, just higher level than assembly.

--
                              Waldek Hebisch