Re: Languages which syntax use minimal punctuation?

Chris Dollin wrote:
goose wrote:

Chris Dollin wrote:
goose wrote:


<snipped>

C++ is particularly hard to parse - but that's not really because
of its /punctuation/. And off-hand it's only the <<>> issues
that are punctuation that affects the parser, surely? Otherwise
its just tokenisation - the parser doesn't care whether
NOT_OPERATOR is spelt ! ¬ NOT not or BIOP17.

True, but if the language itself does not have the not
operator, then theres no need to tokenise and find a
not operator.

True. But I don't see that as significant.

See below where I'll try to explain.


A parser for lisp OTOH needs
( ) # ` , \

And ' " . And rules for tokens. And ,, is different from , , if

? I'm not sure what , , does and you're right about ".

If I recall correctly, it's splice-insert (as opposed to , which
is item-insert). But I haven't CLed for a long time.

actually those are ,@ and , respectively. I don't know
the difference (if any) between ,, and , ,
(perhaps a lisper can chime in on this?)


but for the others:
. yeah, okay I'll have to count that as punctuation.
' doesn't have to be parsed, it will be expanded by the
reader (in the language itself) to (quote ...).

IE the reader is doing work on the language - what the

yes; The less work I have to do in the hosted language,
the better. The more I can implement in the /target/ language
the better. The reason I say this is because the whole reason
for implementing another language *is* to make the problem
solving easier and/or faster, so the more problems I can
solve in the target language the better.

reader is doing /is/ parsing. (The fact that the reader is
written in Lisp isn't the point; it's still part of the
parsing process.)

I recall correctly. And of course once you've formed the
S-expression you still have syntactic rules to impose,
for all the special forms that are not functions. You might
not count those as part of the "parser", but they're part of
the work to be done.

No, I don't count it as a parser; to parse s-exp
is totally seperate from examining it and deciding what
rules to impose.

Yes, in the sense that you can parse non-programs.

No, in the sense that a parsed S-expression need not be a
program, and so the evaluator must apply additional - syntactic -
checks that the reader didn't do. They are just as much part
of the syntax of Lisp as say -> and ?: are part of the syntax
of C.

Well, thats the beauty of it, see? If I seperate the logic
from the parsing so thoroughly, the parsed s-exp can be used
for *more* than just a "program". Like I said the whole idea
for a /new/ language within your program is to make it
easier to solve problems, not just write programs. So for
example, using lisp-like syntax we can have the following
as a program:

(defun factorial (n)
(if (eq n 0)
n
(factorial (- n 1))))

Which our parser will happily accept, and then we'll have
to figure out the logic and tail-call optimisations and execution
order, etc. We can also have the following:

(html
(body
(a :href "http://www.lelanthran.com";
:text "click this link to go to my homepage")
(p :background-color :red
:text "Welcome to my PlayGround,
day")))

Our parser will happily digest that as well, and leave the
interpretation up to something else (html renderer perhaps?)

My (initial) point was that added punctuation usually
add nothing to the logic but requires more work for the
*parser*. In a language like C++ (or the even cleaner
C) the parser has to know about a whole lot of things
that are not really relevant. Things like ; ending
a statement even when a closing brace would suffice
in this example:
if (x>y) {
do_this ();
do_that ();
do_somthing ();
}

In that example, one should be able to leave out the last ;
as it adds nothing of value. Lets take a (hypothetical but
syntactically correct) C++ example.

tcp_conn.connect ("www.lelanthran.com", 80);
tcp_conn.close ();

There is so much superflous punctuation in there that I
do not even know where to start. Lets see, we can remove
the dot and replace with space (1 less punctuation character)

tcp_conn connect ("www.lelanthran.com", 80);
tcp_conn close ();

We can remove the comma in there since arguments
seperated by whitespace are just as readable and easy to
parse.

tcp_conn connect ("www.lelanthran.com" 80);
tcp_conn close ();

We can remove the ( and ) as they are added punctuation
that is needed for only delimiting where the argument
list start and end.

tcp_conn connect "www.lelanthran.com" 80;
tcp_conn close ;

Of course now we have the (simpler) convention that
the argument list starts immendiately after the message
which is the second word immediately after the object name
which is the first word.

We still have the ; seperating each statement but thats
okay 'cos thats not superflous - its necessary.

Each added punctuation character means more processing
by the parser and I'm a simple "parser does nothing
but parse" kinda guy :-).


My point was that it is less work
to parse a lisp-like language (which has minimal punctuation
*and* syntax) than a C++ like language.

It's the simpler syntax that makes it simpler. (I agree that
the syntax of Lisp, even taking /all/ of it into account, is
simpler than the syntax of C++, and it may be easier to handle;
I suspect you also have to take into account the semantics
of both languages too; C's punctuation is there for a
reason, after all.)

And it's possible for a good
choice of surface syntax to make code easier to /read/, by
/humans/, who after all are the entities that need the
most help when reading program text.

In that regard, I would hope that a *simpler* surface syntax
with minimal punctuation and special cases would be easier
to read (by a human) than one which required lots of rules
with a few special cases.

You might hope that, but I don't think that it's true.

EG I find Pop11 code, which has a pretty rich syntax, to be
more readable than Common Lisp code -- /because/ of that

TBH, I considered CL code to be totally incomprehensible
and finally "got it" late one night, in much the same manner
as a prophet having an epiphany :-). Sadly, once I got it
I started seeing ugliness in my previously written babies
(written in C, C++, PHP, Perl, etc).

rich syntax. (I'm not claiming that /everyone/ will feel
that way: some people take to the S-expression style like
ducks to duckponds.)

<goose says>
So now I'm a duck??? :-)
Anyway, I know what you mean. Really, I do.


A human has to memorise punctuation and syntax for the
language in question, and hence has to know when all
the punctuation characters and special cases have to be
used;

The same is true for Lisp /code/, where the surface syntax
is superficially easier but you have to know the individual
rules for the /constructs/ of the language. For example,
(defun 17) isn't a legal construct, although it is a legal
S-expression. If I recall correctly. Similarly for

(setq (+ 1 2) a b)

You recall correctly. Although, seeing my html example
above, note that although it is *not* legal lisp, because
it is consistent you can *make* it legal (write the
proper functions/macros). Were there an abundance of
punctuation characters in the language (like C++),
then that sort of clarity is not an option.


I think it is easier to simply learn 1 or 2 rules
that are applied consistently (Lisp syntax) than learning
an "easier" looking language with lots of rules and
special cases.

You can have rules without /lots/ of special cases. And
there's a difference between "easy to learn" and "easy to
use long-term". I suspect that, for English readers at any
rate, well-chosen punctuation can give compact hints that
uniform S-expression rules don't.

I agree; this is why punctuation is not *absent* from
lisp, just reduced.

(I say "English" just
because I'm a native English reader and don't want to
overover-extend my intuitions.)

I don't know how one could do decent tests for this. The

Sigh. How I would love empirical tests (and results) for
this sort of thing. I, like all developers, want my
scriptable application to be *popular*, not elegant!
Elegance would just be a bonus :-). I'd give my
right arm (well, my bosses right arm:) for excel
level popularity.

If I could only figure out what my intended users (not
native english speakers) found easiest to use I could
have a product that had a shot at becoming popular. As
it is now, I look at various languages (and make up a few
of my own) show it to the wife (or similar)
and ask "What do you think of this?". Thus far smalltalk
and tcl seem the most intuitive to non-programmers, but
YMMV.

only empirical evidence I can think of is that Lisp has
not, in fact, taken over the world - but there are so many
possible reasons for that it's hardly even suggestive.


Lisp won't, in my lifetime, take over the world. This is
because the majority of lisp developers I have come across
don't *want* to take over the world. World-takeovers seem
to be relegated these days primarily to Java and C#
folk.

anyway, this was an enlightening (if slightly long)
discussion; I guess theres still a lot for me to learn.

goose,
C and C++ developers also don't seem to care
about world-domination one way or another.
Theres absolutely no insecurity in those two camps.

.

Relevant Pages

  • Re: Languages which syntax use minimal punctuation?
    ... but if the language itself does not have the not ... okay I'll have to count that as punctuation. ... IE the reader is doing work on the language - what the ... of the syntax of Lisp as say -> and ?: ...
    (comp.programming)
  • Re: Languages which syntax use minimal punctuation?
    ... its just tokenisation - the parser doesn't care whether ... but if the language itself does not have the not ... okay I'll have to count that as punctuation. ... choice of surface syntax to make code easier to /read/, ...
    (comp.programming)
  • Re: PROS/CONS: #define BEGIN {
    ... >>They will produce the same output but the punctuation now takes up much more space. ... > Proper English words are, in my opinion, ... > Tinkering with bits of syntax using DEFINEs ... > or a formal language extension that uses software ...
    (comp.lang.c)
  • Re: Has Forth a punctuation?
    ... punctuation and whatever makes the sugar of a language. ... but syntax is basically just punctuation. ... So Forth will for ever be doomed to have a simulated success? ...
    (comp.lang.forth)
  • Re: What is the best book/way to teach my 12 year old kid to program
    ... The syntax for most languages is defined in at least a spec, ... The parser is a quality of implementation ... oddities and have a fair amount of previous language experience. ... not recommendable for beginning programmers unless they're going to have ...
    (comp.programming)