Syntax free language ? and other issues

[Matthew Tuck]

Otieno Ododa wrote:

> Most of the recent posts to the list read like excerpts from advanced
> compiler/language design theory books (I've never read one, but I
> imagine that these posts resemble them). I don't understand a lot,
> being relatively inexperienced, but I do have a few questions about
> some things.

Yeah, I know I have to start talking about related concepts all the time
and I don't really have time to explain them all.  But if I can try to
explain ideas to someone who's not familiar then I can get a better
handle on explaining them to the world.  So I don't mind repeating
anything that's not obvious.

> I don't know if I understand this correctly. Are you saying that the
> programmer would define how code would look, and define the keywords
> himself, perhaps mapping them to the basic keywords in 'our' language?
> I can only imagine how hard it would be to learn this language, if
> that's the case, but I can't think of any other meaning for it. If I
> don't understand this correctly, I think that it's still likely that a
> default syntax would be required for first learning the language.

Anyone can define a "view", which is basically a small program that
controls how the program looks, how you enter it, and how you modify
it.  You can have several views open at once.  So if you change
something in one view, the others will update.

Each view will work differently, or there's no point in having more than
one other than what you already get with a "split screen".  A view might
be a lot like what we program with today.  Or it might be different.

What views you use are dependent on your choice as a programmer.  You're
free to use standard views, use one someone else wrote, or write one
yourself.

Your choice will have little effect on how it appears to programmers you
distribute your code to.  It appears to them how they want it to appear.

The standard sort of view is textual and has the idea of a syntax.  This
could be any syntax, it's up to the view writer.  The syntax doesn't get
mapped to any other keywords, it gets mapped to the parse tree I talked
about before.

Parse trees have the keywords removed.  They just have concepts like
variables, if-statements, procedures, etc.  As such they are independent
of syntax, and you can apply any set of keywords or even any policy to
them to output them.

As for teaching the language to beginners, they essentially learn the
concepts of the language, not any syntax.  They would obviously program
using a view, but which is irrelevant.  They can stay with that view or
change to another, knowing concepts like procedures, types and
statements will work the same in other views, they just look a bit
different.

> Removal of {} and ()
>      "C-like {} has known problems, and () was never needed. "
> 
> I only recently ventured into more advanced C++ concepts, and I've
> found brackets and parentheses to be very helpful as far as
> determining what code is what, and what code does what. I've
> programmed in x86 assembly and Basic and created simple programs, and
> I have found brackets to be far more helpful than indentation in
> determining what code is in what control structure, even where there
> aren't very many levels of brackets. In addition, I find the keywords
> 'fi' and 'elif' to be painfully gross looking ;), though I have no
> concrete reason for thinking so.

I was fairly ambiguous when I said that, it's easy to fall into the trap
of only talking to who you're replying to.

When I was talking about "{}" I not referring to the characters, just
the concept of "open-form" statements.  That is, statements where you
have something like

if A then B

rather than

if A then
  B
endif

With open-form you have to use a block to get multiple statements in the
scope of the if, e.g.

if A then begin
  B
  C
end

or { and } instead of "begin" and "end" in C.

There are two problems, dangling else and the misplaced statement.

Dangling else asks about the meaning of:

if CondA then if CondB then DoZ else DoY

Is the else bound to the first if or the second?

The misplaced statement is about replacing this:

if CondA then
  DoB

with this:

if CondA then
  DoB
  DoC

The DoC is not under the scope of the if, but looks like it might be.

Closed form avoids both of these problems.  You can also use layout, or
an intelligent editor's indenting as Hans-Dieter suggested.
 
> I like the use of keywords like 'new' and 'delete' to create and
> "uncreate" objects. I even like C\C++'s 'malloc' to allocate memory. I 
> admit that this may be because I've only recently started using them,
> and I'm not sure what could be an improvement on this. I do like the
> fact that, in C++, I can allocate just as much memory as I need, no
> more, and no less.

New is fine.  The programmer still chooses when to allocate the memory. 
It's the delete that is the problem.  What problem?  Well you can delete
a bad pointer, you can delete memory twice and you can forget to delete
memory (memory leak).  If an exception is raised you often find the
program doesn't free memory properly due to programmer oversight. 
Automatic memory management is about getting the system to delete the
objects when they're no longer used.  It doesn't miss any and it doesn't
make mistakes.
 
> Again, I'm no great programmer, and I don't really have a handle on
> the more advanced concepts of compiler theory. Is this language going
> to be minimalist or is it going to have everything but the kitchen
> sink ? What about those who don't think the compiler should handle
> memory allocation (like me, for lack of knowledge, or others, who
> actually have good reasons for it) or at least would like to be able
> to manually allocate/deallocate memory for whatever reason ?

The language is going to be as big as the project members want it to be.

What you put in a language could be debated till the cows come home, and
will be.  Some features are really important.  GC makes the language
simpler (very slightly) too.  The trick is to design features that
subsume other features into a general feature to avoid language bloat.

Given this, many features can be implemented in libraries.  While the
endeavour on the language proper should be clean useful independent
features, libraries can support many many useful facilities to reduce
programmer work.  The same issues are still there, but they are less.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/