comp.lang.dylan discussing non-LISP syntaxes 
Author Message
 comp.lang.dylan discussing non-LISP syntaxes

The readers and writers of comp.lang.dylan are embarking upon a heated
discussion of the desirability or otherwise of an Algol-like syntax.  To
add fuel to the fire I've put a trivial and a near-trivial example of Pop-11
syntax; paid-up members of the Lotsof Irrelevant Silly Parentheses
Considered Unnecessary club (and others) may care to weigh in over there...

Stefek "stir a controversy a day" Zaba



Mon, 14 Aug 1995 03:52:05 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:

> The readers and writers of comp.lang.dylan are embarking upon a
> heated discussion of the desirability or otherwise of an Algol-like
> syntax.  To add fuel to the fire I've put a trivial and a
> near-trivial example of Pop-11 syntax; paid-up members of the Lotsof
> Irrelevant Silly Parentheses Considered Unnecessary club (and
> others) may care to weigh in over there...

Please don't.  You will only meet up with the paid-up members of the
Hate Inconsistent Syntax With Too Many Silly Keywords Club.

--
Brent Benson                    
Harris Computer Systems



Mon, 14 Aug 1995 22:02:34 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:
> Please don't.  You will only meet up with the paid-up members of the
> Hate Inconsistent Syntax With Too Many Silly Keywords Club.

And it would be a crime to hurt their feelings -- just when they're nearly
off the medication.

Steve



Thu, 17 Aug 1995 22:43:53 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:
> The readers and writers of comp.lang.dylan are embarking upon a heated
> discussion of the desirability or otherwise of an Algol-like syntax.

But, in the spirit of the debate, please don't post examples replete with
Pop-11's syntax design errors.  The point is not to expose Pop-11 to a great
deal of merited criticism but to help the Dylan debate consider worthwhile
alternatives to S-expression syntax.

Pop-11 syntax does not walk on water, illuminate the room when bent over,
or even put a smile on the face of a baby.  These days, Pop-11 syntax is
in serious need of repair.  To illustrate this, I shall (rather unfairly)
consider some of the code posted to comp.lang.dylan.

Stefek Zaba posts the following

Quote:
> define global procedure addoncetolist( elem, lis );
>     if member( elem, lis ) then
>         lis
>     else
>         elem :: lis
>     endif;
> enddefine;

Surely no one could consider *this* putrid construct to be worth recommending.
I speak, of course, of the totally horrid qualifiers "global procedure".
Just like the Lispers, we have become inured to writing objectionable
syntax until we can no longer see it.  Note the omission (deliberate?) of
the [unspeakable] declarations of input locals.  Even in passing, Stefek
has cleaned up today's dialect of Pop-11 -- that's how bad it has become.

Stefek adds to the previous with this prize-winning code ....

Quote:
> define search_for_fourth_power_sums();
>     lconstant procedure table =
>         newanyproperty(
>             nil, 2e5, 1, false,
>             procedure; && 16:1FFFFFFF endprocedure, nonop =, false,
>             nil, false
>         );

What is this "lconstant procedure" all about.  If it is lconstant and the
result is a procedure why does the procedure qualifier add anything?  

Quote:
>     lconstant procedure totable = updater( table );

As above.  Both of these should be global variables rather than compile-time
locals.  This was written before "lblock" entered the language.

Quote:
>     define lconstant procedure removetoosmall( key, values, limit );
>         ;;; Apppropery'd every so often to clear out all entries whose key is
>         ;;; <= limit (which happens to get set to the fourth power of "outer")
>         ;;; Frees up a little store.
>         if key <= limit then totable( nil, key ) endif
>     enddefine;

Why declare this as an "lconstant procedure".  This is the obvious default
for procedure definitions.  Again, the syntax is penalising the reader.
Note that the local variables are not declared -- plainly an error.  The
code would be even uglier with the declarations.

Quote:
>     lvars outer=1, inner, sumfours, oldassoc;

Cascaded declarations on the same line.  One is initialised the other isn't.
Why are these non-initial declarations made here rather than at their first
point of use?  Poor syntax design is the answer, yet again.  Because
Pop11 doesn't allow "lvar" declarations to occur on the RHS of an assignment.

Quote:
>     .timediff.erase;

This is clearly an example where Pop11's prefix notation is abused.  At least
we haven't got the seriously loathsome ".timediff ->;"

Quote:
>     repeat forever
>         fast_for inner to outer do

Note that one of the pointlessly declared variables was "inner".
Again, bad syntax design strikes.  If Pop11 declared it's loop variables
automatically, the ugly declaration would be removed, along with the
scope for error.

Quote:
>             (outer.dup.nonop *.dup.nonop *)
>              + (inner.dup.nonop *.dup.nonop *)
>             -> sumfours ;

A worse advertisment for Pop11's syntax cannot be imagined.  This looks
suspiciously like something I wrote.  I soundly castigate myself for
writing this piece of excrement.  What is wrong with
    lvars sumfours = ( outer * outer ) * dup() + ( inner * inner ) * dup()
Which is just as efficient and many times more readable.  It also gets
rid of one of the cascaded declarations.

Quote:
>             table( sumfours ) -> oldassoc;

Again, one of the cascaded variable declarations.  Should be
              lvars oldassoc = table( sumfours );

Quote:
>             totable( conspair( conspair(outer,inner), oldassoc ), sumfours );

>             unless oldassoc == nil then
>                 printf( 'Result at %p with %p after %p seconds\n',
>                     [% table( sumfours ), sumfours, timediff() %] );
>             endunless;
>         endfor;
>         outer + 1 -> outer;
>         if (outer fi_&& 63) == 0 then
>             outer =>
>             appproperty( table,
>                 removetoosmall(% outer.dup.nonop *.dup.nonop * %) );

Ugggh!  Let's lay this out in an elegant fashion and write it cleanly
              apppproperty(
                  table,
                  removetoosmall(%
                      outer * outer * outer * outer
                  %)
              )

Quote:
>         endif;
>     endrepeat;
> enddefine;

Ian Rogers now adds to the fray:

Quote:
> define addoncetolist( elem, lis );
>     if member( elem, lis ) then lis else elem :: lis endif;
> enddefine;

> define addoncetolist( elem, lis );
>     elem :: delete(elem, lis);
> enddefine;

I've no complaints.  I just wish I could write Pop11 in this new syntax.
It is necessary to add the rider that in Pop11, input locals need to be
declared owning to a syntax design fault.

Alas, we continue with ....

Quote:
> Spot the results at a glance, easy peasy, not.
> In lisp:
>     (not (easy-peasey (spot-the-results-at-a-glance)))
> Pop11 prefix:
>     not(easy_peasey(spot_the_results_at_a_glance()))
> Pop11 postfix:
>     .spot_the_results_at_a_glance.easy_peasey.not
> Pop11 mix and match:
>     not(.spot_the_results_at_a_glance.easy_peasey)

I hope that no one writes code like that.  Apart from Chris Dollin who
is a lost cause.  

And then, to air further of Pop11's bizarre quirks, we see Robin
Popplestone with the following sadly flawed example:

Quote:
> And partial application in POP gives even more concise forms E.g.

>  vars procedure(
>    quit      = do_0(%-3%),
>    nest      = do_0(%-2%),
>    power     = do_0(%-1%),
> );

I don't believe there are more than a handful (OK, 2 handfuls) of Pop11
programmers who feel comfortable with the distinction between

    vars procedure ( x = E, y = E );

and

    vars procedure x = E, y = E;

It's not a topic that the books discuss at length -- almost as if the writers
know that the syntax has thrown a wheel and is zooming towards a cliff.
What we want to write is just the following --- and don't hold the white
space ---

    val ( quit, nest, power ) = for i in [-3 -2 -1] do do_0(% i %) endfor;

or just nice and quiet, omitting the cascade,

    val quit  = do_0(% -3 %);
    val nest  = do_0(% -2 %);
    val power = do_0(% -1 %);

We don't want to specify the variables to be procedures or constant, so I've
used the Pepper -val- syntax to get exactly the effect we want.  With -val-
you get constant procedure when in compile_mode +strict and pop_debugging
is false.  Otherwise you just get vars.  Elegant, simple and precise.

Note that I've also assumed the implicit, local, declaration for the
loop variable.  Otherwise we have to write

    val ( quit, nest, power ) =
        lblock
            lvars i;
            for i in [-3 -2 -1] do do_0(% i %) endfor
        endlblock;

which loses something in translation ...

I hope these examples are ample illustration of the state of disrepair
of Pop11's syntax.  Naturally, I wouldn't be yakking on about this unless
I thought there were some straighforward actions that would be taken to
improve matters.  Here's a small list that are brought out by the above
examples:

  (1) Input and output locals should be considered to be declaration
      positions.  e.g.

          define maplist( list, procedure proc ); ....

  (2) Loop variables should be treated the same way.  e.g.

          for i in E do ....
          for dlocal i in E do ....

  (3) The role of the empty expression should be restricted.  In particular
      infix expressions should require non-empty expressions on their
      left and right.

  (4) Default -define- declarations to being "lconstant procedure" when
      inside procedures.

  (5) Introduce a variable declaration (e.g. -val-) which works like
      -define- does with regard to compile_mode +strict and -pop_debugging-.

There are many other things that can be done, too.  And it is really worth
while.  One of the major attractions of Pop11 is its syntax; at the core
Pop11 has one of the best designs in the world.  I'd like to see it stay
that way rather than be whittled away.

Steve



Fri, 18 Aug 1995 00:14:58 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:
> On the other hand they might like to stay where they are and steer
> clear of another pointless debate.  Agree to disagree and leave it at
> that.

'Pointless debate' --- you wouldn't have pre-judged the issue would you?
It's always nice talking with open-minded folks, so I've heard.

Steve



Fri, 18 Aug 1995 19:34:55 GMT  
 comp.lang.dylan discussing non-LISP syntaxes
   The readers and writers of comp.lang.dylan are embarking upon a heated
   discussion of the desirability or otherwise of an Algol-like syntax.  To
   add fuel to the fire I've put a trivial and a near-trivial example of Pop-11
   syntax; paid-up members of the Lotsof Irrelevant Silly Parentheses
   Considered Unnecessary club (and others) may care to weigh in over there...

   Stefek "stir a controversy a day" Zaba

On the other hand they might like to stay where they are and steer
clear of another pointless debate.  Agree to disagree and leave it at
that.

bevan



Fri, 18 Aug 1995 02:16:38 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:

> But, in the spirit of the debate, please don't post examples replete with
> Pop-11's syntax design errors.  The point is not to expose Pop-11 to a great
> deal of merited criticism

I consider my wrist deservedly slapped :)

Quote:
> Ian Rogers now adds to the fray:

> > define addoncetolist( elem, lis );
> >     if member( elem, lis ) then lis else elem :: lis endif;
> > enddefine;

> > define addoncetolist( elem, lis );
> >     elem :: delete(elem, lis);
> > enddefine;

> I've no complaints.  I just wish I could write Pop11 in this new syntax.
> It is necessary to add the rider that in Pop11, input locals need to be
> declared owning to a syntax design fault.

That's a little too harsh. No variables *need* to be declared[1] in
Pop11, you just get the lowest possible form of identifier imagined
;)

I'm reminded that Pop9x can always do with a helping hand. Steve: is
the standard yet at a stage where a programming consortium could be
usefully constructed? How about you and Kers giving a tutorial at
Plug'93?

Ian.

[1] Although try using the variables "form", "man" or "stop" without
declaring them first %-} There's bound to be others.



Fri, 18 Aug 1995 20:27:28 GMT  
 comp.lang.dylan discussing non-LISP syntaxes

Quote:
> > It is necessary to add the rider that in Pop11, input locals need to be
> > declared owning to a syntax design fault.

To this comment Ian remarks:

Quote:
> That's a little too harsh. No variables *need* to be declared[1] in
> Pop11, you just get the lowest possible form of identifier imagined
> ;)

Well I can't help but take Ian's bait.  Now, are these two functions the
same or different?

    define add( e, l ); lvars e, l;
        if member( e, l ) then l else e :: l endif
    enddefine;

    ;;; For the non-Pop readers, this is an explicit version of what you
    ;;; get when defaults are left out.  It is slightly simplified w.r.t.
    ;;; active variable declarations, of course.
    vars elem, lis;
    define add( elem, lis );
        dlocal elem, lis;
        if member( elem, lis ) then lis else elem :: lis endif
    enddefine;

If they are different, which one did you intend to write (and it clearly
matters)?  So, if you got the answers right, I think it is fair to say that
in today's Pop11 you *need* to declare input locals.  And I hate it.  For
goodness sake, even Lisp gets this correct!  And they've had lots of practice
at inventing wonky syntax.

Quote:
> I'm reminded that Pop9x can always do with a helping hand. Steve: is
> the standard yet at a stage where a programming consortium could be
> usefully constructed?

Yes, especially in the sensitive area of new proposals.  As Pop9X stands
it is a {*filter*}-stamp of existing Pop11.  This is for simplicity rather
than anything else.  If we start from a known base then we may cautiously
make progress.

Steve



Sun, 20 Aug 1995 01:20:31 GMT  
 comp.lang.dylan discussing non-LISP syntaxes
   > On the other hand they might like to stay where they are and steer
   > clear of another pointless debate.  Agree to disagree and leave it at
   > that.

   'Pointless debate' --- you wouldn't have pre-judged the issue would you?

Yes, I have pre-judged the issue, the judgement being that I think it
is rather naive of anybody to believe they can change other peoples
opinion on what is essentially a religious issue.

   [ needless ad-hominem deleted ]

bevan



Fri, 25 Aug 1995 02:13:24 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. archives of info-dylan/comp.lang.dylan available

2. Why is J discussed in comp.lang.apl

3. Gatewaying of comp.lang.lisp and common-lisp@mcc.com

4. comp.lang.dylan, FINAL NOTICE of Newsgroup Removal

5. RFD: comp.lang.dylan

6. RFD: comp.lang.dylan

7. Moderating comp.lang.dylan

8. Moderating comp.lang.dylan

9. comp.lang.dylan archives

10. comp.lang.dylan

11. RESULT: comp.lang.dylan passes 349:11

12. CFV: comp.lang.dylan

 

 
Powered by phpBB® Forum Software