Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[pjb@informatimago.com (Pascal J. Bourguignon)]

"bartc" <bartc@freeuk.com> writes:

> "tm" <thomas.mertes@gmx.at> wrote in message
> news:ffe34647-ed6d-4349-beb1-3f613351439d@v36g2000yqv.googlegroups.com...
>> On 25 Jul., 00:29, "bartc" <ba...@freeuk.com> wrote:
>>> The Pascal design is elegant but I've done parsers where potentially
>>> thousands of tokens need to be processed after a parenthesis before it
>>> knows
>>> exactly what it's dealing with. It's not a problem.
>>
>> The problem is not that it is not doable.
>> The problem is that human readers must also process
>> thousands of tokens to know exactly what is going on.
>
> This really means it needs to look ahead a complete expression, which can be
> of arbitrary complexity, especially if expressions can include statements as
> my design did. Examples:
>
> (expr)              # ordinary parenthesised expression
> (expr | a | b)      # if-then-else select
> (expr | a,b,c | z)  # n-way select
> (expr, a,b,c)       # list
>
> a[expr]             # normal indexing
> a[expr..expr]       # slicing
> etc...
>
> In practice expr will be short and only a few symbols (such as
> n+1). If the user wants to put almost a whole program in there, that's
> up to him. And he could probably do similar things in Pascal and
> Seed7.
>
>> When one symbol tells you, what is going on, reading is easier.
>> Complicated parsing with lookahead is IMHO an indication
>> for hard to read constructs.
>
> You can't argue the above construct's aren't easy on the eye. On the other
> hand:
>
> switch n
> when x then a
> when y then b
> else c
> end [i]:=k
>
> is probably ill-advised. It's not until the end that you realise it's an
> assignment to an array element (ie. assigning k to one of a[i], b[i] or
> c[i]).

It's ill-advised, but because of the ill-definition of that language.
There's no reason why such an expression couldn't be written and read
easily.  You just need to design your language with prefix operators
(Polish Notation) so you always know up-front what you're parsing:

(setf (aref (switch n
              (x    a)
              (y    b)
              (else c)) i) k)

Which is even simplier than what Wirth was about.


> (expr)              # ordinary parenthesised expression

expr              ; if you take care of always parenthesize
                  ; expressions,  you simplify the syntax
                  ; rules and don't need to further parenthesize
                  ;  expressions.

> (expr | a | b)      # if-then-else select

(if expr a b)


> (expr | a,b,c | z)  # n-way select

(select expr a b c z)


> (expr, a,b,c)       # list

(list expr a b c)


> a[expr]             # normal indexing

(aref a expr)


> a[expr..expr]       # slicing

(slice a expr1 expr2


> etc...

etc...


> So it all depends. Parsing this stuff is trivial. Might as well make it
> available, and trust the user to use it sensibly.

-- 
__Pascal Bourguignon__