Re: [racket-dev] P4P: A Syntax Proposal

[Eli Barzilay]

On Jul 31, Guillaume Marceau wrote:
> I've never seen student in a beginner course work this way. As an
> experiment, I invite you to try programming without using tab, and
> without deleting blocks of parenthesis at once. I suspect you will
> develop sympathy for these students who "hate parentheses".

I have no idea what kind of crowd I'd be a representative of, but --
(a) I use tab *very* rarely (only when modifying some big chunk of
code so the nesting level changes, and in less than 25% of these
cases); (b) I practically never remove parens and leave an unbalanced
buffer.


> Why would this be less of a problem in curly brace languages?
> 
> First, there are just many more parentheses in a Racket program. As
> Matthias was saying, we use a lot of nested expressions, and
> function call dictate nearly everything. So, in a curly brace
> language, when a student is trying to re-infer their parenthesis
> structure, there are fewer of them, so it isn't as hard.
> 
> Second, the grammar markers in a curly brace language have names on
> them. They use "then" to separate the predicate from the answer, we
> use ")(". It is much easier to re-infer intentionality of the
> former.  The latter is just another a bunch of parenthesis floating
> amongst other anonymous parentheses.

[

All this sounds questionable to me.  IMO, the main paren-related
difference between a racket program and a C program, is that nested
function calls are more common in the first than in the second,
otherwise

int foo(int x) { return x; }
(define (foo x) x)

have the same number of parens.  Also, modern curely brace languages
almost never use `then' and we don't use ")(" -- so at least for the
predicate <--> true branch you have whitespace in both cases; other
special forms in curely braces are usually not using keywords beyond
the openning one.  ("Anonymous parentheses" reminds me of the pascal
days where the language was much more keyword-full, yet it was common
to decorate an "end" with a comment saying what it ends.)

]

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jens Axel Søgaard]

2010/7/31 Eli Barzilay :

> There's a whole bunch of these things (in CL and Scheme), and IIRC,
> Jens had something very well doone recently -- but they all suffer
> from requiring some ugly wrapper syntax around them.

Indeed. In order to keep the wrapping at a minimum I contemplate
hijacking "strings starting with $", that is, if a string starts with $ then
the remaining part of the string is parsed as an infix expression.
I came to my senses eventually.

http://planet.racket-lang.org/package-source/soegaard/infix.plt/1/0/planet-docs/manual/index.html

-- 
Jens Axel Søgaard
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Matthias Felleisen]

On Jul 31, 2010, at 12:38 AM, Guillaume Marceau wrote:

1. Shriram never clarified that this proposal is for attracting students only. 
If so, I'd like to see a path from P4P to full Racket syntax included in the 
proposal. 

2. 

> I also don't think "I hate parentheses" comes from familiarity with
> some other syntax,

I have not run into a "I hate parentheses" attitude in my time of teaching this 
material -- except in teacher workshops, usually stated as "my students will 
hate all these parentheses when I will teach this stuff in the fall". Even 
though you are entirely focused on watching students and interviewing them, I 
am sure that in my 18 years of watching freshmen at two colleges and N high 
schools over the first few weeks I should have encountered this problem. 

I have encountered the "I hate Scheme" attitude a lot in college. To counter 
that, I have developed a simple and easy trick. I invite the people who say 
this or a variation on it ("I can solve these problems in any other language 
than Scheme" or such) to solve the problem in their favorite language; if they 
can I promise an A for the semester. I do this two or three times a semester 
and all of these kids leave my office with the admission that they are having a 
problem and it is NOT Scheme. 

If you and Shriram think that this is a problem that pervades the semester -- 
more than the first two weeks in a regular semester (NEU, Brown NOT WPI) -- the 
proposal presentation should include statistical evidence. 

-- Matthias

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Michael Sperber]

Matthias Felleisen  writes:

> 1. Indentation matters. This point is entirely orthogonal to syntax. 
>It applies to Racket and Honu as well. 

t's been a long time (several years) since I've heard substantial
complaints about parens or prefix syntax from beginning students.  Also,
since we've emphasized indentation a bit more, they generally get
indentation right.  What they *don't* get right is line breaks: They all
act like they're writing code on their 38" TVs.  (Kind of surprising to
me, given that it's the texting/twitter generation.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Several things to reply to, but before I get to them, it's critical
that I fix this misconception:

>  2. I doubt that we can figure out the usefulness of this new syntax
>  on this mailing list.

I am not trying to.  I only posted it here because I figured having
lots of eyes look at it would likely yield some interesting feedback.
And that has indeed been the case.  I don't think a mailing list is
going to resolve this one way OR the other (so for the same reason, I
am also ignoring the dismissive tone of some of the postings here).

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] P4P: A Syntax Proposal

[Guillaume Marceau]

On Fri, Jul 30, 2010 at 10:52 AM, Matthias Felleisen
 wrote:
>
> Programmers who complain about parens mean something larger:
>  -- the entire syntax (it doesn't look traditional)
>  -- the entire semantics (function calls dictate nearly everything)
>  -- the way we program (inductive structures have more weight than indexed 
> ones)
> and more and certainly all the 'syntactic' symptoms that come with this:
>  -- nested expressions show up a lot; how to read them
>  -- array/for-loop "patterns" of programming aren't working, how to start?
>  -- why this focus on data representations, can't we just use arras?
> And I am sure the list of such make-me-feel-bad unfamiliarities goes on.


I'll give a different theory.

My theory starts with the observation that students who program in BSL
spend an inordinate amount of time fiddling with parentheses. It's
exhausting, non-fun work. I think students are blaming the
parentheses simply because that is what is under their nose most of
the time.

One thing we have learned from the interviews is, they might hate the
parentheses, but they love the gray highlight tool of DrRacket. By
mid-semester, they use it accurately, and skillfully. Their technique
looks like this: the student clicks on a closing parenthesis, sees
which constructs it is closing, and then tries to remember the
original intention for that closing parenthesis. They are checking
whether that parenthesis is closing what they meant it to close. This
takes a lot of time, as they are constantly re-inferring the
intentionality of their closing parentheses.

Professional programmers don't do this. Why not?

First, we rely on indentation, visually, and also procedurally. We
press "tab" on a line that should be correctly indented, and if the
line moves, we know there is a problem. Second, we don't adjust
parentheses one at the time. After editing a section of code, we
delete the entire block of closing parentheses, "))])]))", then we
press close until the next line tabs to the right place.

I've never seen student in a beginner course work this way. As an
experiment, I invite you to try programming without using tab, and
without deleting blocks of parenthesis at once. I suspect you will
develop sympathy for these students who "hate parentheses".

Why would this be less of a problem in curly brace languages?

First, there are just many more parentheses in a Racket program. As
Matthias was saying, we use a lot of nested expressions, and function
call dictate nearly everything. So, in a curly brace language, when a
student is trying to re-infer their parenthesis structure, there are fewer
of them, so it isn't as hard.

Second, the grammar markers in a curly brace language have names on
them. They use "then" to separate the predicate from the answer, we
use ")(". It is much easier to re-infer intentionality of the former.
The latter is just another a bunch of parenthesis floating amongst
other anonymous parentheses.

If this theory holds, then P4P should help a great deal. P4P enforces
indentation, so students will have to start paying attention to it
(they really don't at the moment). P4P also reduces the number of
parentheses overall, and it puts names on the grammar markers.



I concur with Shriram. I don't think prefix notation for arithmetic is
a problem. Early in the course they will sometime write an infix
expression by mistake, but the error message they receive quickly
prompts them to the right fix. I don't see them struggling with this.
I also don't think "I hate parentheses" comes from familiarity with
some other syntax, or from familiarity with arrays. The feeling seem
just as common amongst non-majors who have never seen any programming
before.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Eli Barzilay]

On Jul 30, Robby Findler wrote:
> Given SK's teaching goals of "all of these operators are really the
> same" and

BTW, if this is a *goal* of this thing, then I don't see where plain
sexpr syntax fails -- if it's just an experiment in reducing the
number of parens then it seems like a risky thing to me, but in
addition I don't see a reason to tie reducing parens with the op(arg,
arg, ...) syntax.  (Sorry if this is in the manifesto text, I'm not on
a convenient machine...)


> Eli's (implicit?) goal of "lets get wider hacker-types
> interested" perhaps the right thing is to have a special infix-like
> mode that you can switch into with a keyword (ala what was discussed
> earlier in this thread)? This would be a special purpose mode where
> there is some simple rule that distinguishes infix operators from
> prefix ones (perhaps something like Haskell's convention)?

There's a whole bunch of these things (in CL and Scheme), and IIRC,
Jens had something very well doone recently -- but they all suffer
from requiring some ugly wrapper syntax around them.  I think that the
usual curly syntax (C, Java, JS, etc) is a (sad) requirement -- which
is why I hope that the Honu thing will work well enough to be used
independent of the bindings that get used (that is, that I'll be able
to use it with the current racket flavors).

(I've just seen some C# video where he talked about the addition of a
`dynamic' type to the language -- the impressive part of that was
demonstrating how you take some C#+JS code, and move the JS code into
C# -- which requires changing a few syntactic keywords and keeping the
code the same.  It's kind of annoying (in a familiar way, since it's
the same Java story), but the bottom line is that Shriram's thing is
very far from that.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Joe Marshall]

On Fri, Jul 30, 2010 at 5:30 AM, Shriram Krishnamurthi  
wrote:
>
> My experience teaching Scheme beginners is that Lisp-style prefix for
> arithmetic is NOT a problem; they get the hang of it quickly.  It's
> when things start to nest and parens start to add on that they start
> to get frustrated.  (COND is a special pet peeve.)

If I dig through the remainder of my memory, I recall that I found COND just
a tad tricky.  It was LET that I had problems with.  I used to write
out the expansion
((lambda (foo bar) body) (baz x) (quux y)) and then `unexpand' it
(let ((foo (baz x))
  (bar (quux y)))
   body)

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Matthias Felleisen]

I see two different points in this proposal. 

1. Indentation matters. This point is entirely orthogonal to syntax. 
   It applies to Racket and Honu as well. 

2. Syntax matters. But I don't understand whether the proposal is 
   really for students only or for students and then a lot more. 
   If it were for the former, I wouldn't expect any discussion of 
   Racket macros in the design document. I'll treat it for now as
   "it is initially for students but it should accommodate everyone." 


On Jul 29, 2010, at 2:09 PM, Shriram Krishnamurthi wrote:

> I think parens are synecdoche.

This is true and easier said than with a rarely used word. 

Programmers who complain about parens mean something larger: 
 -- the entire syntax (it doesn't look traditional) 
 -- the entire semantics (function calls dictate nearly everything)
 -- the way we program (inductive structures have more weight than indexed ones)
and more and certainly all the 'syntactic' symptoms that come with this: 
 -- nested expressions show up a lot; how to read them
 -- array/for-loop "patterns" of programming aren't working, how to start? 
 -- why this focus on data representations, can't we just use arras? 
And I am sure the list of such make-me-feel-bad unfamiliarities goes on. 

Assuming that the lack of syntactic familiarity outweighs the others
 -- something we don't know for sure -- I think the next question 
to ask is how much distance to 'real' or 'familiar' syntax these 
'targeted' people can tolerate. 

After reading the entire document and looking at the sample
programs, I remain unconvinced in two ways: 

 1. I tend to agree with Eli's general point and his arithmetic 
example illustrates this point really well. 

 2. I doubt that we can figure out the usefulness of this new 
syntax on this mailing list. 

I really think we need a reasonably large-scale experiment and that 
worries me. With such an experiment a lot of things need to be considered:

 -- say we stick with +(1,2,3) and people don't come, what went wrong? 
they considered +(1,2,3) too distant from 1 + 2 + 3 
they didn't like identifiers such as posn-x 
they disliked the semantic distance, i.e., they wanted to 
  write p.x not posn-x(p) because they think they don't 
  care when p is not a posn struct 
in general, who knows what to conclude from a failure

 -- conducting this experiment on students will lead to very 
different results than conducting it on 'real' programmers
Where should we start? Personally I think students are the 
_wrong_ audience. They can cope with () and this prefix
notation in the middle is something they are guaranteed 
_not_ to encounter elsewhere. 

 -- how much work do we have to invest to make it so robust that it 
works as well as Javascript? 
I think you have a nice prototype and it's roughly were
Honu was a while back. But we need much much more to 
get the full power of Racket with P4P. 

And I am sure you can imagine many more questions that we 
should discuss before we spend the resources. 

I for one am looking forward to a robust discussion of this 
topic at PLT day. 

-- Matthias

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Dave Gurnell]

Hi all,

I thought I'd mention Scala's behaviour, which could be relevant. Any 
single-operator method like:

class X {
def method(arg: Y): Z = { ... }
}

can be written as an infix operator:

val answer = x method y

as well as the traditional dot/paren syntax.

Scala uses a set of hard-coded rules to determine precedence and left/right 
associativity from the name of the method. When I first saw this I thought it 
was completely mad (still do to an extent), but it does make for readable code.

Cheers,

-- Dave

On 30 Jul 2010, at 15:11, Robby Findler wrote:

> Given SK's teaching goals of "all of these operators are really the
> same" and Eli's (implicit?) goal of "lets get wider hacker-types
> interested" perhaps the right thing is to have a special infix-like
> mode that you can switch into with a keyword (ala what was discussed
> earlier in this thread)? This would be a special purpose mode where
> there is some simple rule that distinguishes infix operators from
> prefix ones (perhaps something like Haskell's convention)?
> 
> Robby
> 
> On Fri, Jul 30, 2010 at 9:05 AM, Eli Barzilay  wrote:
>> On Jul 30, Robby Findler wrote:
>>> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay  wrote:
 IMO, this thing is missing the point (the usual "parens, ewww!"
 one), as long as it ignores infix.
>>> 
>>> Seems to me that this point directly contradicts one of Shriram's
>>> design goals, namely showing that + is no more special than append
>>> or one of your own functions.
>> 
>> To make my point better: I think that this (treating them all the
>> same) is exactly what makes people dislike it.  Whether the open
>> paren appears before the function or after it, and whether you
>> separate arguments by spaces or commas is a minor point that is easy
>> to get adjusted too.  As an experiment, try these:
>> 
>>  (< (^ x 2) (/ d 10))
>>  <(^(x, 2), /(d, 10))
>>  x^2 < d/10
>> 
>> I obviously see the simplicity and elegance of the first.
>> I can certainly see the point that makes people want the third.
>> 
>> But the second looks like a mixed up version of the first, which makes
>> it harder to follow (I actually wrote it "top-down" since it didn't
>> make any sense otherwise).  So I don't see any advantages for the
>> second -- *especially* through the eyes of the many people who
>> complain about sexprs, and OTOH, I see a huge disadvantage (which
>> might be just me not being used to the open paren shift and the comma,
>> so if that cost goes away I'm left with a syntax that is redundantly
>> incompatible with sexprs).
>> 
>> And yes -- this is an arithmetic example, and most code is not
>> arithmetic, still -- it's these places that bother me (and seem to
>> bother others) most when it gets to sexpr syntax.  Avoiding infix
>> altogether (and even SK's manifesto has just a comment about not using
>> it) is IMO sticking your head in the sand, and makes the whole thing
>> look like the N+1th step in a long series of amusing posts in various
>> places that end up with no practical results besides a long discussion
>> thread.
>> 
>> --
>>  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
>>http://barzilay.org/   Maze is Life!
>> 
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Robby Findler]

Given SK's teaching goals of "all of these operators are really the
same" and Eli's (implicit?) goal of "lets get wider hacker-types
interested" perhaps the right thing is to have a special infix-like
mode that you can switch into with a keyword (ala what was discussed
earlier in this thread)? This would be a special purpose mode where
there is some simple rule that distinguishes infix operators from
prefix ones (perhaps something like Haskell's convention)?

Robby

On Fri, Jul 30, 2010 at 9:05 AM, Eli Barzilay  wrote:
> On Jul 30, Robby Findler wrote:
>> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay  wrote:
>> > IMO, this thing is missing the point (the usual "parens, ewww!"
>> > one), as long as it ignores infix.
>>
>> Seems to me that this point directly contradicts one of Shriram's
>> design goals, namely showing that + is no more special than append
>> or one of your own functions.
>
> To make my point better: I think that this (treating them all the
> same) is exactly what makes people dislike it.  Whether the open
> paren appears before the function or after it, and whether you
> separate arguments by spaces or commas is a minor point that is easy
> to get adjusted too.  As an experiment, try these:
>
>  (< (^ x 2) (/ d 10))
>  <(^(x, 2), /(d, 10))
>  x^2 < d/10
>
> I obviously see the simplicity and elegance of the first.
> I can certainly see the point that makes people want the third.
>
> But the second looks like a mixed up version of the first, which makes
> it harder to follow (I actually wrote it "top-down" since it didn't
> make any sense otherwise).  So I don't see any advantages for the
> second -- *especially* through the eyes of the many people who
> complain about sexprs, and OTOH, I see a huge disadvantage (which
> might be just me not being used to the open paren shift and the comma,
> so if that cost goes away I'm left with a syntax that is redundantly
> incompatible with sexprs).
>
> And yes -- this is an arithmetic example, and most code is not
> arithmetic, still -- it's these places that bother me (and seem to
> bother others) most when it gets to sexpr syntax.  Avoiding infix
> altogether (and even SK's manifesto has just a comment about not using
> it) is IMO sticking your head in the sand, and makes the whole thing
> look like the N+1th step in a long series of amusing posts in various
> places that end up with no practical results besides a long discussion
> thread.
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Eli Barzilay]

On Jul 30, Robby Findler wrote:
> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay  wrote:
> > IMO, this thing is missing the point (the usual "parens, ewww!"
> > one), as long as it ignores infix.
> 
> Seems to me that this point directly contradicts one of Shriram's
> design goals, namely showing that + is no more special than append
> or one of your own functions.

To make my point better: I think that this (treating them all the
same) is exactly what makes people dislike it.  Whether the open
paren appears before the function or after it, and whether you
separate arguments by spaces or commas is a minor point that is easy
to get adjusted too.  As an experiment, try these:

  (< (^ x 2) (/ d 10))
  <(^(x, 2), /(d, 10))
  x^2 < d/10

I obviously see the simplicity and elegance of the first.
I can certainly see the point that makes people want the third.

But the second looks like a mixed up version of the first, which makes
it harder to follow (I actually wrote it "top-down" since it didn't
make any sense otherwise).  So I don't see any advantages for the
second -- *especially* through the eyes of the many people who
complain about sexprs, and OTOH, I see a huge disadvantage (which
might be just me not being used to the open paren shift and the comma,
so if that cost goes away I'm left with a syntax that is redundantly
incompatible with sexprs).

And yes -- this is an arithmetic example, and most code is not
arithmetic, still -- it's these places that bother me (and seem to
bother others) most when it gets to sexpr syntax.  Avoiding infix
altogether (and even SK's manifesto has just a comment about not using
it) is IMO sticking your head in the sand, and makes the whole thing
look like the N+1th step in a long series of amusing posts in various
places that end up with no practical results besides a long discussion
thread.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> deffun: d/dx(f) =
>   defvar: delta = 0.001
>   fun: (x) in
>      ((f((x + delta)) - f(x)) / delta)

Just to be pedantic, I've changed the "in" to "in:", because I want to
have a consistent rule for all key*words*.

> Which can be understood easier than the prefix version but avoids all
> the negatives of a complete infix notation.

What you're doing is essentially recapping an age-old Lisp tradition
of defining infix macros (my guess is the first one was probably
written a few weeks after s-expressions got adopted as the programming
notation).  I don't have a problem with that.  I don't want to use
"in:" as the name for an infix construct, but maybe just "i:"
(especially if people are going to use it often, keeping it short will
help).  But I also don't want to spend time on that right now because
I don't think it's where the big payoff is.

> deffun: d/dx(f) =
>   defvar: delta = 0.001
>   fun: (x) in
>      in:(in:( f( in:(x + delta) ) - f(x)) / delta) ; not as pretty...

No, once you're in infix, you can stay there:

deffun: d/dx(f) =
  defvar: delta = 0.001
  fun: (x) in:
i:((f(x+delta) - f(x)) / delta)

As I said in another message, I think I made a mistake by using
arithmetic examples, because they represent the worst-case for this
syntax.  Real code will have much less arithmetic.

> Since your target use if for students, I could be convinced that infix
> doesn't belong.  ¡  But both students and experienced (non-LISP)
> programmers will complain about the prefix math. (And prefix comparison
> operators.)

My experience teaching Scheme beginners is that Lisp-style prefix for
arithmetic is NOT a problem; they get the hang of it quickly.  It's
when things start to nest and parens start to add on that they start
to get frustrated.  (COND is a special pet peeve.)

> BTW, any binary operation that expresses a relationship between first
> and second operands could be clarified by writing it in infix.

Except conventionally, I hear no clamor for being able to say

  (+ . map . l)

or even

  (10 . expt . 2)

The bottom line, though, is that I don't have a problem with having a
parenthesized infix term offset by a keyword.

> Also, if P4P is dependent on keywords like if: elif: etc. then macros
> are crippled unless they can also make use of key words.

I'm afraid I totally don't understand what you're saying.

> Other examples:
>   filter( lst ) with:(elem) { odd?(elem) }
> -->
>   (filer lst #:with (lambda (elem) (odd? elem)))

filter:  with:  
-->
(filter  (lambda () ))

I'm failing to see what is "cripping" here that #:with did not carry
over into Racket.  The idea is to create a surface syntax that
entirely hides the Racket layer underneath, so who cares whether the
Racket layer uses intermediate keywords or not?

Given that I am totally, completely, utterly missing your point, I'm
sure you must have one.  Try again?

> The switch example shows one more instance where someone will want to
> define a structure that you haven't thought of.   I believe you said cond
> will just have to be a bunch of if/elif.   But someone will still want to
> implement cond.   If you can't handle creating new structures in your
> syntax then P4P will only be useful to students.

Please see the section on syntax extensions in the manifesto.  I
thought I'd already addressed this.

>  It won't help pull
> parenthesis-haters into the Racket camp (unless you implement all the
> structures they could wish for in your parser, since
> non-schemers/lispers aren't used to creating new syntaxes with macros).

Naturally, P4P will have to offer a term for each of the syntactic
constructs in Racket.  Functions come for free.  So they would have
the whole language available to them.  So what's the problem?

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[John Clements]

On Jul 30, 2010, at 6:47 AM, Robby Findler wrote:

> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay  wrote:
>> IMO, this thing is missing the point (the usual "parens, ewww!" one),
>> as long as it ignores infix.
> 
> Seems to me that this point directly contradicts one of Shriram's
> design goals, namely showing that + is no more special than append or
> one of your own functions.

That may be true, but it doesn't counter Eli's point, which I think is entirely 
valid.  I had precisely the same reaction when I saw that code.

John 



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> Seems to me that this point directly contradicts one of Shriram's
> design goals, namely showing that + is no more special than append or
> one of your own functions.

Precisely.  And a point that Emu makes very well in Bootstrap.

Also, when is Honu getting indentation?

It's clear that putting out examples primarily filled with arithmetic
was a bad idea, because it focuses on the syntactically least
appealing part.  Frankly, people do not have a problem when they first
see arithmetic:

3 -> 3
1+2 -> (+ 1 2)
5*2 + 3*4 -> (+ (* 5 2) (* 3 4))

The problems always come later.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Robby Findler]

On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay  wrote:
> IMO, this thing is missing the point (the usual "parens, ewww!" one),
> as long as it ignores infix.

Seems to me that this point directly contradicts one of Shriram's
design goals, namely showing that + is no more special than append or
one of your own functions.

Robby
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Eli Barzilay]

IMO, this thing is missing the point (the usual "parens, ewww!" one),
as long as it ignores infix.  I was contemplating some examples that
would demonstrate this nicely, and then I saw this:

On Jul 28, Shriram Krishnamurthi wrote:
> deffun: d/dx(f) =
>   defvar: delta = 0.001
>   fun: (x) in
> /(-(f(+(x, delta)),
> f(x)),
>   delta)
> 
> defvar: d/dx-of-square = d/dx(fun: (x) in *(x,x))
> =(round(d/dx-of-square(10)), 20.0)
> =(round(d/dx-of-square(25)), 50.0)

which (again -- IMO) is barely readable for people who know a little
about sexpr syntax, and probably completely unreadable for most
people.

(And, of course, doing infix gets a whole bunch of heavy stuff in --
the redundant parens, stricter syntax for identifiers, etc; I have
high hopes for the honu reader.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett]

On Thu, 2010-07-29 at 15:37 -0400, Shriram Krishnamurthi wrote:
> Quick addendum:
> 
> > Infix notation can be achieved unambiguously if you use LL(1) with
> > backtracking instead of just LL(1) by accepting expressions in the form
> > "(a b c)" that become "b(a, c)".   This is unambiguous only if you do not
> > allow including useless parenthesis around expressions
> 
> This would not be a good idea.  Students are taught that infix goes
> hand-in-hand with useless parens -- "if in doubt, add parentheses, you
> can add as many as you want".  So giving them infix syntax but NOT
> permitting useless parens would fry their circuits.
> 
> Shriram

I thought it was a clever idea because it forces parens around each
individual use, so the programmer has to think of associativity and
precedence, but allows a more readable representation.  So the d/dx
example becomes:

deffun: d/dx(f) =
  defvar: delta = 0.001
  fun: (x) in
((f((x + delta)) - f(x)) / delta)

Which can be understood easier than the prefix version but avoids all
the negatives of a complete infix notation.

The same could, of course, be accomplished with a macro (in a op b) ->
(op a b).  But in P4P that would end up looking like in(1, +, 2) which
isn't quite as nice.  Maybe yet another keyword for in:(1 + 2).
deffun: d/dx(f) =
  defvar: delta = 0.001
  fun: (x) in
in:(in:( f( in:(x + delta) ) - f(x)) / delta) ; not as pretty...


Since your target use if for students, I could be convinced that infix
doesn't belong.  But both students and experienced (non-LISP)
programmers will complain about the prefix math. (And prefix comparison
operators.)

BTW, any binary operation that expresses a relationship between first
and second operands could be clarified by writing it in infix.  So a
function application "match(string, pattern)" could be "(string match
pattern)".  So allowing infix does not destroy the understanding that +
is not any more special than any other function.


Also, if P4P is dependent on keywords like if: elif: etc. then macros
are crippled unless they can also make use of key words.  I believe Honu
somehow makes structural keywords unspecial, but requires redefining the
standard library (making the Honu language in addition to
H-Expressions).  An idea I had, but haven't worked the kinks out of yet,
was something like:
  if( cond ) then: {
expr-true
  } else: {
expr-false
  }
-->
  (if cond #:then expr-true #:else expr-false)
which also requires redefining the standard library.

Other examples:
  filter( lst ) with:(elem) { odd?(elem) } 
-->
  (filer lst #:with (lambda (elem) (odd? elem)))
and
  switch(val)
case:("hello") { ... }
else: { ... }
-->
  (cases val #:case (lamda ("hello") ...) #:else ...)
which would require the macro look in the param list of the case's
lambda to find the pattern to match instead of in groupings of parens.

The switch example shows one more instance where someone will want to
define a structure that you haven't thought of.  I believe you said cond
will just have to be a bunch of if/elif.  But someone will still want to
implement cond.  If you can't handle creating new structures in your
syntax then P4P will only be useful to students.  It won't help pull
parenthesis-haters into the Racket camp (unless you implement all the
structures they could wish for in your parser, since
non-schemers/lispers aren't used to creating new syntaxes with macros).

-Everett

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Quick addendum:

> Infix notation can be achieved unambiguously if you use LL(1) with
> backtracking instead of just LL(1) by accepting expressions in the form
> "(a b c)" that become "b(a, c)".   This is unambiguous only if you do not
> allow including useless parenthesis around expressions

This would not be a good idea.  Students are taught that infix goes
hand-in-hand with useless parens -- "if in doubt, add parentheses, you
can add as many as you want".  So giving them infix syntax but NOT
permitting useless parens would fry their circuits.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Neil Van Dyke]

Shriram, you can disregard my point.

I didn't do a good job of making the small point I intended: if one of 
the goals is to remove the kneejerk objection to sexp paren syntax 
(which I think is a familiarity thing), even after dispensing with sexp 
parens, you still have the things like the 
whoa-another-punctuation-character-what-does-it-mean "let*:", etc. 
making code look unfamiliar.


But I see that you've already stated that as not being within your 
problem scope, and/or you also have the mitigating internal "defvar", so 
you can disregard my point.


--
http://www.neilvandyke.org/

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

All good questions.

I certainly explicitly work to make all *functions* "pass through".

I can't guarantee that for syntactic forms.  I'm currently
re-exporting the whole Racket language, which might be leading to the
strange interaction you're seeing.

Dotted infix syntax: An infix-by-syntax-hack won't work well with P4P:
the language has too much syntax to "slide in" something like this.

I'd like to make so that syntactic forms can "pass through" with
minimal work, probably using the do:-style to achieve it for a
quick-and-dirty solution.

Shriram

On Thu, Jul 29, 2010 at 9:57 AM, Guillaume Marceau  wrote:
> How does P4P interact with existing macros? How much work does it take
> to make a macro such as require/contract available to P4P programs?
>
>
> Is there an equivalent of the dotted-infix syntax in P4P? What would
> the following line look like in P4P? :
>
>    (provide/contract [process (path-string? path-string? (listof
> symbol?) . -> . any)])
>
>
> Right now, if I run
>
>   #lang s-exp "p4p.rkt"
>   require(srfi/1)
>
> I get the error
>
>   require: not at module level or top level in: require
>
> Is this a bug?
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

They do stand for a bigger thing, but I think they also stand for themselves.

That is, as I said earlier in this thread, issues like composition and
nesting ARE difficult and students DO have difficulty adjusting to
them.

But we should not assume that they are the ONLY problem, and that the
syntax is no problem at all.  At least, that isn't my evidence.

Shriram

PS: I've been around this discussion enough times w/ Joe that I don't
think it's fruitful.  I'm taking this as an axiom; Joe takes the
negation of this as an axiom.  So I'd like to focus on discussion of
P4P itself.  In particular, it'd be great to get some feedback from
others who try it out.

On Thu, Jul 29, 2010 at 2:12 PM, Robby Findler
 wrote:
> Okay, I just looked that up and I'm still not sure what you mean. :)
>
> Robby
>
> On Thu, Jul 29, 2010 at 1:09 PM, Shriram Krishnamurthi  
> wrote:
>> I disagree.  I think parens are synecdoche.
>>
>> Shriram
>>
>> On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
>>  wrote:
>>> FWIW, I think you're probably right that "parens" are actually code
>>> for "I don't want to think so hard" so while an alternative syntax may
>>> take away one excuse, language design and libraries and good docs and
>>> tutorials all the other things are probably going to be required as
>>> well to really make the language a success.
>>>
>>> Robby
>>>
>>> On Thu, Jul 29, 2010 at 12:19 PM, Joe Marshall  
>>> wrote:
 On Wed, Jul 28, 2010 at 3:06 PM, Everett  wrote:
> I've always thought the problem was the parens.

 I don't believe this.  If the parens were the problem, then why didn't
 M-expressions gain popularity?  Why didn't CGOL?  Why didn't Dylan?
 Why hasn't *any* alternative syntax helped? (Honu, anyone?)

 And why aren't parens a problem in C:

          if (unlikely(!access_ok(VERIFY_READ, iocbpp, 
 (nr*sizeof(*iocbpp)
                return -EFAULT;

 or Java?

        private static void defCategory(String name,
                                        final int typeMask) {
            map.put(name, new CharPropertyFactory() {
                    CharProperty make() { return new Category(typeMask);}});
        }

 --
 ~jrm
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Robby Findler]

Okay, I just looked that up and I'm still not sure what you mean. :)

Robby

On Thu, Jul 29, 2010 at 1:09 PM, Shriram Krishnamurthi  
wrote:
> I disagree.  I think parens are synecdoche.
>
> Shriram
>
> On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
>  wrote:
>> FWIW, I think you're probably right that "parens" are actually code
>> for "I don't want to think so hard" so while an alternative syntax may
>> take away one excuse, language design and libraries and good docs and
>> tutorials all the other things are probably going to be required as
>> well to really make the language a success.
>>
>> Robby
>>
>> On Thu, Jul 29, 2010 at 12:19 PM, Joe Marshall  
>> wrote:
>>> On Wed, Jul 28, 2010 at 3:06 PM, Everett  wrote:
 I've always thought the problem was the parens.
>>>
>>> I don't believe this.  If the parens were the problem, then why didn't
>>> M-expressions gain popularity?  Why didn't CGOL?  Why didn't Dylan?
>>> Why hasn't *any* alternative syntax helped? (Honu, anyone?)
>>>
>>> And why aren't parens a problem in C:
>>>
>>>          if (unlikely(!access_ok(VERIFY_READ, iocbpp, 
>>> (nr*sizeof(*iocbpp)
>>>                return -EFAULT;
>>>
>>> or Java?
>>>
>>>        private static void defCategory(String name,
>>>                                        final int typeMask) {
>>>            map.put(name, new CharPropertyFactory() {
>>>                    CharProperty make() { return new Category(typeMask);}});
>>>        }
>>>
>>> --
>>> ~jrm
>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>>
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

I disagree.  I think parens are synecdoche.

Shriram

On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
 wrote:
> FWIW, I think you're probably right that "parens" are actually code
> for "I don't want to think so hard" so while an alternative syntax may
> take away one excuse, language design and libraries and good docs and
> tutorials all the other things are probably going to be required as
> well to really make the language a success.
>
> Robby
>
> On Thu, Jul 29, 2010 at 12:19 PM, Joe Marshall  wrote:
>> On Wed, Jul 28, 2010 at 3:06 PM, Everett  wrote:
>>> I've always thought the problem was the parens.
>>
>> I don't believe this.  If the parens were the problem, then why didn't
>> M-expressions gain popularity?  Why didn't CGOL?  Why didn't Dylan?
>> Why hasn't *any* alternative syntax helped? (Honu, anyone?)
>>
>> And why aren't parens a problem in C:
>>
>>          if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)
>>                return -EFAULT;
>>
>> or Java?
>>
>>        private static void defCategory(String name,
>>                                        final int typeMask) {
>>            map.put(name, new CharPropertyFactory() {
>>                    CharProperty make() { return new Category(typeMask);}});
>>        }
>>
>> --
>> ~jrm
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

That's why internal defvar: exists.  Most of the time, this is what I
expect people will want and use, just like local variable definitions
in other languages (except done right, w/out bizarro scope-lifting
crud).

Unusually for you, your remark seems vacuous.  (P4P, and I quote::
"This is purely about syntax. The semantics of P4P is precisely that
of Racket."  Neil, and I paraphrase: "P4P forces you to know about the
semantics of Racket.")  So maybe I've missed your point.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Neil Van Dyke]

These most recent examples with "let:", "let*:", and "letrec:" highlight 
that users of P4P still need to know about Racket semantic distinctions 
that other languages don't provide the programmer. (Instead, they might 
have a more familiar "var" or "def", for example.)


So I bet that Racket code in P4P is still looking obtuse to many of the 
same people who refuse to try sexp syntax.


(I'm not discouraging this P4P line of inquiry, and I'm curious to see 
where it goes.)


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

On Wed, Jul 28, 2010 at 7:23 PM, Barland, Ian  wrote:

> * Any p4p equivalents for the other racket constructs which use extra-parens
> (mostly: let and named-let)?

As you wish!

I'm currently not supporting named-let.  Meanwhile, my in-flight work
for this morning:

let:
  x = 3,
  y = 2
 in:
  +(x, y)

let*: x = 3, y = x in: +(x, y)

letrec: even = ;; perversely written as a one-liner
   fun: (n) in: if: zero?(n) true else: odd?(sub1(n)),
odd = fun: (n) in:
if: zero?(n)
  false
else:
  odd?(sub1(n))
 in: list(odd?(10), even?(10))

Note the new indentation rule, described in the manifesto.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Robby Findler]

FWIW, I think you're probably right that "parens" are actually code
for "I don't want to think so hard" so while an alternative syntax may
take away one excuse, language design and libraries and good docs and
tutorials all the other things are probably going to be required as
well to really make the language a success.

Robby

On Thu, Jul 29, 2010 at 12:19 PM, Joe Marshall  wrote:
> On Wed, Jul 28, 2010 at 3:06 PM, Everett  wrote:
>> I've always thought the problem was the parens.
>
> I don't believe this.  If the parens were the problem, then why didn't
> M-expressions gain popularity?  Why didn't CGOL?  Why didn't Dylan?
> Why hasn't *any* alternative syntax helped? (Honu, anyone?)
>
> And why aren't parens a problem in C:
>
>          if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)
>                return -EFAULT;
>
> or Java?
>
>        private static void defCategory(String name,
>                                        final int typeMask) {
>            map.put(name, new CharPropertyFactory() {
>                    CharProperty make() { return new Category(typeMask);}});
>        }
>
> --
> ~jrm
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Joe Marshall]

On Wed, Jul 28, 2010 at 3:06 PM, Everett  wrote:
> I've always thought the problem was the parens.

I don't believe this.  If the parens were the problem, then why didn't
M-expressions gain popularity?  Why didn't CGOL?  Why didn't Dylan?
Why hasn't *any* alternative syntax helped? (Honu, anyone?)

And why aren't parens a problem in C:

  if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(*iocbpp)
return -EFAULT;

or Java?

private static void defCategory(String name,
final int typeMask) {
map.put(name, new CharPropertyFactory() {
CharProperty make() { return new Category(typeMask);}});
}

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett]

So the dotted style is a shortcut for
(let ([a $B("name")])
  (let ([b changes(a)])
(let ([c calmE(b 300)])
  c)))
which is another way to show the sequential nature of the data flow.

As a macro you can write:

(define-syntax-rule (. var exp next)
  '(let ([,var ,exp]) next))

(. b (. a $B("name") changes(a)) calmE(b 300))

And that also looks similar.  No idea if this is any help...

-Everett

On Thu, 2010-07-29 at 10:00 -0700, Joe Marshall wrote:
> On Wed, Jul 28, 2010 at 3:27 PM, Shriram Krishnamurthi  
> wrote:
> > Quoting from our Flapjax paper (pg 12):
> > This means that instead of
> >
> >  var name = calmE(changes($B("name")), 300);
> >
> > developers can write
> >
> >  var name = $B("name").changes().calmE(300);
> >
> > which is arguably more readable than standard functional notation,
> > since the left-to-right order of operations corresponds to the
> > direction of dataflow.
> >
> > -
> >
> > What I didn't admit there is that *I* prefer the dotted style for this
> > kind of sequential pipeline.
> 
> There are a couple of serious problems with the dotted style.  First,
> in most languages that use this notation, the `method name' (the token
> immediately after the dot) is scoped within the class of the object.  Methods
> are generally *not* first-class objects.  This means that you cannot write
> something like:
>   deffun: callit (object, method) =
> object.method()
> 
> The second problem is that what is *really* happening is a function call,
> but the first (or second, depending how you count) argument is for some
> unexplained reason separated from the others and placed in a weird position.
> For example, in this:
>   >  var name = $B("name").changes().calmE(300);
> 
> Is it immediately obvious to you that calmE takes *two* arguments?
> Can you explain why the second argument isn't treated the same way?
> 
> -- 
> ~jrm
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Unfortunately for the rhetorical point you're trying to make, *I*
don't have trouble with your questions, partly because I've thought
about this for a while in the context of Flapjax, and partly because I
generally agree with criticisms of object-centric viewpoints.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Joe Marshall]

On Wed, Jul 28, 2010 at 3:27 PM, Shriram Krishnamurthi  
wrote:
> Quoting from our Flapjax paper (pg 12):
> This means that instead of
>
>  var name = calmE(changes($B("name")), 300);
>
> developers can write
>
>  var name = $B("name").changes().calmE(300);
>
> which is arguably more readable than standard functional notation,
> since the left-to-right order of operations corresponds to the
> direction of dataflow.
>
> -
>
> What I didn't admit there is that *I* prefer the dotted style for this
> kind of sequential pipeline.

There are a couple of serious problems with the dotted style.  First,
in most languages that use this notation, the `method name' (the token
immediately after the dot) is scoped within the class of the object.  Methods
are generally *not* first-class objects.  This means that you cannot write
something like:
  deffun: callit (object, method) =
object.method()

The second problem is that what is *really* happening is a function call,
but the first (or second, depending how you count) argument is for some
unexplained reason separated from the others and placed in a weird position.
For example, in this:
  >  var name = $B("name").changes().calmE(300);

Is it immediately obvious to you that calmE takes *two* arguments?
Can you explain why the second argument isn't treated the same way?

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> That's only true if {} count as parens too.  ¡  My suggestion was that
> they ONLY count as a begin statement.

So what do I do in the case of expressions-in-function-position?
Currently that is the one source of ambiguity in the language, so it
is essential that I deal with that.  Using {...} in the function
position addresses it.  [It's fugly, but rather rarely seen in code.]

> ¡  I could live with "do: {}", I
> was just trying to reduce the typing and number of keywords a bit.

Understood, and I greatly appreciate the suggestions.

> Which basically means P4P syntax is not indentation based, it just
> has an extra style checker component added into the
> parser.   (Personally I think the style checker should be part of the
> IDE, not enforced by a compiler since it has nothing to do with
> whether a program is parsable.)

I've never said it is indentation-based.  You won't find that phrase
anywhere in the document.  Indeed, the documentation repeatedly says
that indentation does not play the role people think, precisely to
ward off misunderstandings like Mike's.  Finally, the documentation
even says how and why one might turn the indentation off.

If your point is that this design conflates two things -- paren
reduction and indentation -- you're right.  But turning off the
indentation checking is trivial: make two (soon to be three, with the
next release) predicates -- or the higher-order predicate invoker --
always return true.  It would take under 10 lines to define that
language and use it instead.  So I'd rather put the effort into the
harder language.  It seems to me an interesting experiment to
understand this intermediate point in the design space, where
indentation is enforced without impacting the semantics.  As an
end-user, when I stick my students in front of such a language, I
really want both aspects.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett Morse]

On Jul 29, 2010, at 9:51 AM, Shriram Krishnamurthi wrote:

> On Thu, Jul 29, 2010 at 9:12 AM, Michael Sperber
>  wrote:
>> Well, except for a bunch of renamings (... in the direction of
>> ... Common Lisp ...?), that doesn't really show yet.
> 
> I'm not going to repeat what I've already explained in detail in the
> document.  (If the document isn't clear, I'd be happy to clarify, but
> you don't seem to be asking questions based on the document at all.)
> 
> If I understand correctly, SRFI-49 essentially inserts parens
> according to indentation.  Thus, if you changed indentation, you could
> change the meaning of the program.
> 
> P4P *checks* indentation but does not let indentation define meaning.
> 

Which basically means P4P syntax is not indentation based, it just has an extra 
style checker component added into the parser.  (Personally I think the style 
checker should be part of the IDE, not enforced by a compiler since it has 
nothing to do with whether a program is parsable.)

> Shriram
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

-Everett
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett Morse]

On Jul 29, 2010, at 9:47 AM, Shriram Krishnamurthi wrote:

> Responding to Everett's suggestion:
> 
>>> I don't understand why not write a lexer, since replacing "do: ()" with
>>> "{}" is the most natural and readable thing to do.
>> 
>> I really don't want to touch the lexer level.
>> 
>> Until this morning, I didn't know how to check for { ... }, which is
>> why I had the do: keyword.   It appears that I can get rid of it.   I
>> have to decide now whether I want to.   I'll think about that.
> 
> I can't get rid of it.  Currently,
> 
>  do: { f(x) }
> 
> is unambiguously a single-statement/expression begin, without having
> to look at subsequent context.  If I make it optional, then the same
> phrase could be either the interpretation above, or a begin with a
> single expression, but where that expression is an application, whose
> function position is a complex expression (namely, f(x)).
> 
> In general, I am very wary of anything optional.
> 
> Shriram

That's only true if {} count as parens too.  My suggestion was that they ONLY 
count as a begin statement.  I could live with "do: {}", I was just trying to 
reduce the typing and number of keywords a bit.

-Everett
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

On Thu, Jul 29, 2010 at 9:12 AM, Michael Sperber
 wrote:
> Well, except for a bunch of renamings (... in the direction of
> ... Common Lisp ...?), that doesn't really show yet.

I'm not going to repeat what I've already explained in detail in the
document.  (If the document isn't clear, I'd be happy to clarify, but
you don't seem to be asking questions based on the document at all.)

If I understand correctly, SRFI-49 essentially inserts parens
according to indentation.  Thus, if you changed indentation, you could
change the meaning of the program.

P4P *checks* indentation but does not let indentation define meaning.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Responding to Everett's suggestion:

>> I don't understand why not write a lexer, since replacing "do: ()" with
>> "{}" is the most natural and readable thing to do.
>
> I really don't want to touch the lexer level.
>
> Until this morning, I didn't know how to check for { ... }, which is
> why I had the do: keyword.   It appears that I can get rid of it.   I
> have to decide now whether I want to.   I'll think about that.

I can't get rid of it.  Currently,

  do: { f(x) }

is unambiguously a single-statement/expression begin, without having
to look at subsequent context.  If I make it optional, then the same
phrase could be either the interpretation above, or a begin with a
single expression, but where that expression is an application, whose
function position is a complex expression (namely, f(x)).

In general, I am very wary of anything optional.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Guillaume Marceau]

How does P4P interact with existing macros? How much work does it take
to make a macro such as require/contract available to P4P programs?


Is there an equivalent of the dotted-infix syntax in P4P? What would
the following line look like in P4P? :

(provide/contract [process (path-string? path-string? (listof
symbol?) . -> . any)])


Right now, if I run

   #lang s-exp "p4p.rkt"
   require(srfi/1)

I get the error

   require: not at module level or top level in: require

Is this a bug?
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Michael Sperber]

Shriram Krishnamurthi  writes:

> They're very different, actually.  And Per Bothner's final post on the thread 
> --
>
> http://srfi.schemers.org/srfi-49/mail-archive/msg00021.html
>
> -- points in the direction of P4P, not SRFI-49.

Well, except for a bunch of renamings (... in the direction of
... Common Lisp ...?), that doesn't really show yet.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

They're very different, actually.  And Per Bothner's final post on the thread --

http://srfi.schemers.org/srfi-49/mail-archive/msg00021.html

-- points in the direction of P4P, not SRFI-49.

Shriram

On Thu, Jul 29, 2010 at 4:15 AM, Michael Sperber
 wrote:
>
> Just a note, it does look not entirely unsimilar to:
>
> http://srfi.schemers.org/srfi-49/srfi-49.html
>
> (For a good chuckle, look at the discussion archive.)
>
> --
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Michael Sperber]

Just a note, it does look not entirely unsimilar to:

http://srfi.schemers.org/srfi-49/srfi-49.html

(For a good chuckle, look at the discussion archive.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

I just don't think your first example is a very good one.  It's sort
of a randomly, absurdly complicated way of writing 6.  The good
examples for HOFs all take them as parameters.

As for stepping, even in Scheme,

  ((lambda ... ...) ...)

is not something they have necessarily seen EVEN if they've seen
functions-as-values (since I argue those are not the natural first
examples), and that's going to appear when stepping.  So either the
stepper needs to mask such syntax, or they have to be prepared for the
truth.  I don't think P4P makes things worse.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Barland, Ian]

>>   - The whole distinction between operators and functions is a lie!
>>
> Except it's not.  I've run into educators who taught Scheme who
> thought this way, and the accounts of Scheme they gave were nonsense.
>
Perhaps I overspoke; it was the idea that I didn't need *two* syntaxes for
calling (arithmetic) functions that impressed me.  I was easily impressed,
in my youth :-)


>> * Are the brackets around expressions-in-function-position required, or
>> optional?
>
> Essential.  That's how parsing stays unambiguous.  (That's why I have
> a do: keyword, not just {...}, as Everett proposed.)
>
Whoops, I see that now; "fun: (x) in identity(x)(3)" would be ambiguous.
Amazing how actually writing down an example can help :-)


>> I ¹d prefer optional, again just for pedagogical elegance when
>> introducing anonymous functions
>
> Not true at all.  Here are two examples:
>
Yeah, most examples work fine; it's just that a very-first example of fun:
might just be an application; I present "{fun: (x) in +(x,x)}(3)" and that
example would likely be the first and last time I type curly-brackets in
class.  Also, if stepping, they can appear:

  defvar: double = fun: (x) in +(x,x)
  double(3)

A hand-eval begins by substituting the identifier (`double`), but we need to
add curly-braces even though there weren't any up in the text of the def'n:

double(3)
  = {fun: (x) in (+x,x)}(3)  ;Where'd the curly-braces appear from, prof?

(Not a biggie, and moot now that I agree that the curly-brace can¹t be made
optional.)



"P4P" -- a palliative for parentheses?


--Ian

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Hi Ian,

>   - The whole distinction between operators and functions is a lie!

Except it's not.  I've run into educators who taught Scheme who
thought this way, and the accounts of Scheme they gave were nonsense.
I'm not saying this (nonsensical semantics) is a necessary consequence
of thinking like this, but keeping them distinct is wise.  As the
manifesto says, ":" means, "Look out!  Not a function call!"

> A friendly amendment/proposal (feel free to
> reject it out-of-hand):
>      if( a,b, elif: c,d, else: e)

Consider it rejected out-of-hand. (-:

> * Any p4p equivalents for the other racket constructs which use extra-parens
> (mostly: let and named-let)?

Sure.  I can add let:.

> * Are the brackets around expressions-in-function-position required, or
> optional?

Essential.  That's how parsing stays unambiguous.  (That's why I have
a do: keyword, not just {...}, as Everett proposed.)

> I ¹d prefer optional, again just for pedagogical elegance when
> introducing anonymous functions

Not true at all.  Here are two examples:

=

deffun: d/dx(f) =
  defvar: delta = 0.001
  fun: (x) in
/(-(f(+(x, delta)),
f(x)),
  delta)

defvar: d/dx-of-square = d/dx(fun: (x) in *(x,x))
=(round(d/dx-of-square(10)), 20.0)
=(round(d/dx-of-square(25)), 50.0)

=

deffun: mymap(f, l) =
  if: empty?(l)
empty
  else:
cons(f(first(l)), mymap(f, rest(l)))

mymap(add1, list(1, 2, 3))

=

No braces anywhere.

You need them ONLY when the function position is a non-identifier
expression.

> (I might be missing something, but I think now that you ¹re using
> curly-brackets, you not only get back non-ambiguity but you also regain
> predictable parsing even if curly-brackets are optional??)

The former is true.  I believe the latter is false.  If I see
something bracketed, is it the optional bracket being made manifest,
or is it the function position expression?

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Barland, Ian]

I will definitely use p4p next time I teach racket to beginners.

* My only qualms are about "do:" and "if:" as keywords, instead of more
function-like syntax.  Looking back at what I found beautiful and elegant
and liberating about scheme the very first time I saw it:
  - The whole distinction between operators and functions is a lie!
  - The whole distinction between control-flow and functions is a lie!
Well, I¹m exaggerating on that second one; at the time I only realized that
viewing "if" as a function was way cool.  (The fact that it's not exactly a
function never bothered me.)

The difference between "do: { a b c }" and "do(a, b, c)" doesn't seem worth
a new keyword to me.  (But if it is, it should definitely use curly-brackets
as you mention.)  I concede that the keyword might do better at gaining
acceptance from people who balk at scheme's apparent lack of control-flow.

I appreciate the reasons you mention for introducing if:,elif: (about
counting parity, and less parens-for-nesting); I'm just personally reluctant
to give up if-as-function.  A friendly amendment/proposal (feel free to
reject it out-of-hand):
if( a,b, elif: c,d, else: e)
where students would realize the keywords `elif:` and `else:` are
meaningless except for indenting/human-readability.  Perhaps the keywords
would even be optional -- either they're all there, or none of them are;
beginner-level could require them.  (I suppose if I really wanted this I
could write my own macro versions, though I'm guessing that wouldn't play
nice with p4p's auto-indenter.) ...hmm, my proposed asymmetry between the
words "if" and "elif:" is confusing though.


* Any p4p equivalents for the other racket constructs which use extra-parens
(mostly: let and named-let)?


* Are the brackets around expressions-in-function-position required, or
optional?  I¹d prefer optional, again just for pedagogical elegance when
introducing anonymous functions, and when using the stepper to replace an
identifier with it's `fun:` value.
(I might be missing something, but I think now that you¹re using
curly-brackets, you not only get back non-ambiguity but you also regain
predictable parsing even if curly-brackets are optional??)


I look forward to trying out p4p.  I've always felt a wee bit hypocritical
saying "scheme emphasizes the connections between programming and math", and
then turning around and correcting the all the years of K-12 notation
"f(x,y)".

--Ian
(who perhaps should have been using honu for quite a while now?)

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

>  Even without Scheme
> syntax extension to simplify things, the simple economizing of typing ""
> instead of "});});" would help, IMHO.
>
> Here's a real-world example that I blogged earlier this year: I had just
> then typed the line of code "annosJson);});}});}".

My favorite is these two lines:

  {title: placesToShow[j].name}));});})
(i);};}

In P4P, as currently constituted, two of the braces disappear, and
there aren't any semi-colons.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Neil Van Dyke]

Everett wrote at 07/28/2010 06:06 PM:
  (map (lambda (x) ...) 
   lst)

is more readable in the Ruby form:
  map(lst) {|x| ... }
or even in Javascript with Prototype:
  lst.each(function(x) {
...
  });
  


I'll respectfully differ with that last assertion.

In my JavaScript experience the last couple years (with plain, jQuery, 
Dojo, and AIR), subjectively speaking, that boilerplate syntax quickly 
gets unreadable once you start nesting syntax nontrivially.  And nesting 
is commonplace when you're doing normal real-world AJAX-y things like 
finding a DOM element to attach a callback that does asynchronous 
XmlHttpRequest that has a completion callback that checks some status 
and conditionally iterates over some DOM query to apply some 
transformation...  Even without Scheme syntax extension to simplify 
things, the simple economizing of typing "" instead of "});});" 
would help, IMHO.


Here's a real-world example that I blogged earlier this year: I had just 
then typed the line of code "annosJson);});}});}".  (That break in the 
pattern is intended.)  Actually, I had typed that with JavaScript 
idiomatic line breaks and indentation before, and I felt it was even 
harder to get right and read with the line breaks.  In Scheme, I 
would've just hit ")" until paren-matching showed that I'd closed the 
syntax to the desired level.  And then the conventional Lisp-y 
indentation and/or paren highlighting would've made the code more 
'visual' than the JavaScript.  Again, IMHO.


Regarding the IMHOs, someone roll out the gaze trackers and brain MRIs 
already. :)


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> Infix goes beyond just arithmetic, ruby allows this sort of syntax
>
> some_list.map{...}.filter{...}.map{...}.fold_right{...}
>
> Which I find much more readable than
>
> (fold-right (map (filter (map some_list)))

That has actually been very much on my mind for a while now.  Quoting
from our Flapjax paper (pg 12):

-

Functions versus Objects

Flapjax encourages making Web applications more functional in
style. This can, however, lead to deeply nested function applications,
which are syntactically alien to many JavaScript developers. We have
therefore found it convenient to make all the standard functions
available as methods in the Behavior and EventStream prototypes. This
means that instead of

  var name = calmE(changes($B("name")), 300);

developers can write

  var name = $B("name").changes().calmE(300);

which is arguably more readable than standard functional notation,
since the left-to-right order of operations corresponds to the
direction of dataflow. We do offer all these operations as standard
functions also, so developers can use whichever style they favor.

-

What I didn't admit there is that *I* prefer the dotted style for this
kind of sequential pipeline.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jon Rafkind]

Infix notation can be achieved unambiguously if you use LL(1) with
backtracking

...which I didn't want to do.

Pedagogically, it has been immensely valuable to explain to kids that
+ and - aren't some special thing, but are just mere operators -- and
so are string-append and image-overlay and so on.

Plus, there isn't much arithmetic in many Scheme programs, which means
the quantity of actual infix is small.


Infix goes beyond just arithmetic, ruby allows this sort of syntax

some_list.map{...}.filter{...}.map{...}.fold_right{...}

Which I find much more readable than

(fold-right (map (filter (map some_list)))
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> I believe the idea was not to convert people who like s-exprs but rather
> to attract all those other programmers (including beginners) who don't
> like them.   (It might also help convince older CS dept people to allow
> changing the intro CS course to H2DP using a non-parenthesis syntax.)

Precisely!  Couldn't have put it better -- thanks.

> I don't understand why not write a lexer, since replacing "do: ()" with
> "{}" is the most natural and readable thing to do.

I really don't want to touch the lexer level.

Until this morning, I didn't know how to check for { ... }, which is
why I had the do: keyword.  It appears that I can get rid of it.  I
have to decide now whether I want to.  I'll think about that.

>  It also would allow
> "when:" to expect one argument by default since "when: {}" is easy to
> write.

That would be fine.  I'll think about that, too.

> Infix notation can be achieved unambiguously if you use LL(1) with
> backtracking

...which I didn't want to do.

Pedagogically, it has been immensely valuable to explain to kids that
+ and - aren't some special thing, but are just mere operators -- and
so are string-append and image-overlay and so on.

Plus, there isn't much arithmetic in many Scheme programs, which means
the quantity of actual infix is small.

> Did the proposal address how quoting/unquoting could be done on P4P
> syntax (for macros, etc.), or how to make a list?   I suppose "list(a, b,
> c)" would work, but do we not have "'(a, b, c)" or something too?

I had some trouble getting quote to work.  It seems like it should not
be a problem.  But it's on my list.  I haven't thought about
unquoting, though it should be possible in principle.  (It's always
been on the todo list at the top of the implementation file.)

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett]

I've always thought the problem was the parens.  But I just realized
that besides prefix and excessive parens there is one more problem, and
that is using function application to encode structure.

E.g. (if c t f) is really structure.  Shriram's syntax handles this by
adding in extra markers for readability.

E.g. 
  (map (lambda (x) ...) 
   lst)
is more readable in the Ruby form:
  map(lst) {|x| ... }
or even in Javascript with Prototype:
  lst.each(function(x) {
...
  });

-Everett

On Wed, 2010-07-28 at 16:36 -0400, Shriram Krishnamurthi wrote:
> People already struggle with nesting.  Excessive parens make
> composition look much harder than it is.  Ergo, my desire to remove
> all unnecessary parentheses.
> 
> While agreeing on goals (integration w/ reader, etc.), I'm ultimately
> less interested in H-expressions than in the surface language.  That
> is, I want a good surface syntax *with* a good back-end.
> 
> Shriram
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Hari Prashanth]

I have heard students saying that they did not like Scheme syntax/parans 
even after using it for a whole semester. I really, to this day, haven't 
understood why they did not like parans. But given an option some people
might start liking it/using it. I feel it would be a great idea to have 
P4P as an alternate. 

Hari

- Original Message -
From: "Neil Van Dyke" 
To: "Jos Koot" 
Cc: "PLT Developers" 
Sent: Wednesday, July 28, 2010 4:44:51 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] P4P: A Syntax Proposal

Jos Koot wrote at 07/28/2010 04:00 PM:
> With a good editor, like that of DrSceme, pardon me, RdRacket, I experience 
> no difficulty at all with parentheses.

As I believe Shriram said, the problem is the *perceptions* of people 
who think that parens are bad, not whether parens are actually bad.

For decades, Lisp people have been saying "Try parens!  You'll like 'em 
once you try 'em!" but that argument has not been as persuasive as we 
might've hoped in getting people to try.

Regarding P4P, I have no real opinion on whether offering people a 
parens-free syntax is a good idea, so long as people who wish to use 
parens are not somehow marginalized somewhere along the line.

-- 
http://www.neilvandyke.org/

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Everett]

@Jos
I believe the idea was not to convert people who like s-exprs but rather
to attract all those other programmers (including beginners) who don't
like them.  (It might also help convince older CS dept people to allow
changing the intro CS course to H2DP using a non-parenthesis syntax.)

@Shrirm
I don't understand why not write a lexer, since replacing "do: ()" with
"{}" is the most natural and readable thing to do.  It also would allow
"when:" to expect one argument by default since "when: {}" is easy to
write. (Whereas the current proposal is to make when: be a do:-style
construct since writing "when: do: ()" is a bit much.)  If you wish to
encourage placing the closing paren/curly-brace on it's own line then
use curly-braces because that is what people are used to doing.  It
takes advantage of pre-formed associations.  Parens mean expression
grouping or function application, curly-braces mean blocks of code or
definition structure.

Infix notation can be achieved unambiguously if you use LL(1) with
backtracking instead of just LL(1) by accepting expressions in the form
"(a b c)" that become "b(a, c)".  This is unambiguous only if you do not
allow including useless parenthesis around expressions, since if you
could add in arbitrary parens you could write "(a (+) (c))" which could
be the expression "a[+](c)" or could be "(a + c)" -> "+(a, c)". Usually
extra parens are not allowed in Racket, but I wasn't sure if you kept
the same restriction.  I have been using this idea in a syntax I'm
experimenting with, but the idea of allowing infix by forcing
parenthesis to solve associativity/precedence was stolen from Niel
Toronto.

Did the proposal address how quoting/unquoting could be done on P4P
syntax (for macros, etc.), or how to make a list?  I suppose "list(a, b,
c)" would work, but do we not have "'(a, b, c)" or something too?

-Everett

On Wed, 2010-07-28 at 22:00 +0200, Jos Koot wrote:
> With a good editor, like that of DrSceme, pardon me, RdRacket, I experience
> no difficulty at all with parentheses. In fact I hardly see them. DrRacket
> shows me the extent of a subsexpr very micely. I would have, may be, a
> problem when parsing symbolic expressions lacking parenteses, unless, of
> course, reading a sexpr with omission of unecessary parentheses would give
> me an old fashioned parenthesized sexpr. I am not convinced, yet ...
> Jos
> 
> > -Original Message-
> > From: dev-boun...@racket-lang.org 
> > [mailto:dev-boun...@racket-lang.org] On Behalf Of Shriram 
> > Krishnamurthi
> > Sent: 28 July 2010 19:45
> > To: PLT Developers
> > Subject: [racket-dev] P4P: A Syntax Proposal
> > 
> > I've been vexed for a while about parenthetical syntax: I 
> > love it, appreciate what it offers, but also recognize that 
> > no amount of teaching or arguing alters how people perceive 
> > it.  With the switch to Racket, and our continuing interest 
> > in user interface issues, I believe it is wise to consider an 
> > optional alternate syntax.
> > 
> > I finally had a breakthrough last weekend on how to create a 
> > syntax that may be more palateable without losing the essence 
> > of parenthetical syntax.  As a preview, it does incorporate 
> > indentation, but in a good way.  You'll see.
> > 
> > Feedback welcome.  The most important is whether you spot any 
> > flaws regarding predictable parsing.
> > 
> > Here's a *non-permanent* URL where you can learn more:
> > 
> >   http://www.cs.brown.edu/~sk/tmp/P4P/
> > 
> > Shriram
> > _
> >   For list-related administrative tasks:
> >   http://lists.racket-lang.org/listinfo/dev
> 
> 
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

On Wed, Jul 28, 2010 at 4:44 PM, Neil Van Dyke  wrote:

> As I believe Shriram said, the problem is the *perceptions* of people who
> think that parens are bad, not whether parens are actually bad.

If we step outside our (parenthetical) cubby-hole, we might be forced
to explain how we can be so sure parens are *not* a problem, at least
for a good many beginners.

> Regarding P4P, I have no real opinion on whether offering people a
> parens-free syntax is a good idea, so long as people who wish to use parens
> are not somehow marginalized somewhere along the line.

I doubt there's any danger of that.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Neil Van Dyke]

Jos Koot wrote at 07/28/2010 04:00 PM:

With a good editor, like that of DrSceme, pardon me, RdRacket, I experience no 
difficulty at all with parentheses.


As I believe Shriram said, the problem is the *perceptions* of people 
who think that parens are bad, not whether parens are actually bad.


For decades, Lisp people have been saying "Try parens!  You'll like 'em 
once you try 'em!" but that argument has not been as persuasive as we 
might've hoped in getting people to try.


Regarding P4P, I have no real opinion on whether offering people a 
parens-free syntax is a good idea, so long as people who wish to use 
parens are not somehow marginalized somewhere along the line.


--
http://www.neilvandyke.org/

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

People already struggle with nesting.  Excessive parens make
composition look much harder than it is.  Ergo, my desire to remove
all unnecessary parentheses.

While agreeing on goals (integration w/ reader, etc.), I'm ultimately
less interested in H-expressions than in the surface language.  That
is, I want a good surface syntax *with* a good back-end.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

Good, then you're not my target audience.

On Wed, Jul 28, 2010 at 4:00 PM, Jos Koot  wrote:
> With a good editor, like that of DrSceme, pardon me, RdRacket, I experience
> no difficulty at all with parentheses. In fact I hardly see them. DrRacket
> shows me the extent of a subsexpr very micely. I would have, may be, a
> problem when parsing symbolic expressions lacking parenteses, unless, of
> course, reading a sexpr with omission of unecessary parentheses would give
> me an old fashioned parenthesized sexpr. I am not convinced, yet ...
> Jos
>
>> -Original Message-
>> From: dev-boun...@racket-lang.org
>> [mailto:dev-boun...@racket-lang.org] On Behalf Of Shriram
>> Krishnamurthi
>> Sent: 28 July 2010 19:45
>> To: PLT Developers
>> Subject: [racket-dev] P4P: A Syntax Proposal
>>
>> I've been vexed for a while about parenthetical syntax: I
>> love it, appreciate what it offers, but also recognize that
>> no amount of teaching or arguing alters how people perceive
>> it.  With the switch to Racket, and our continuing interest
>> in user interface issues, I believe it is wise to consider an
>> optional alternate syntax.
>>
>> I finally had a breakthrough last weekend on how to create a
>> syntax that may be more palateable without losing the essence
>> of parenthetical syntax.  As a preview, it does incorporate
>> indentation, but in a good way.  You'll see.
>>
>> Feedback welcome.  The most important is whether you spot any
>> flaws regarding predictable parsing.
>>
>> Here's a *non-permanent* URL where you can learn more:
>>
>>   http://www.cs.brown.edu/~sk/tmp/P4P/
>>
>> Shriram
>> _
>>   For list-related administrative tasks:
>>   http://lists.racket-lang.org/listinfo/dev
>
>
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jon Rafkind]

 On 07/28/2010 02:19 PM, Shriram Krishnamurthi wrote:

On Wed, Jul 28, 2010 at 2:31 PM, Jay McCarthy  wrote:

At first I thought, how is this different than Honu?

I don't know anything about Honu.  As far as I can tell it's the great
undead language of the Racket world.  If Honu's already solved the
problem and is being actively used, great, I can stop!  I didn't know
Honu enforced indentation -- when did it start doing so?

Honu doesn't enforce indentation. I think the main differences between 
the honu syntax and P4P are infix notation and how macros work. I hope 
to get Honu into a useable enough state before PLT day that people can 
at least write simple programs, we'll see how it goes.


BTW, my personal opinion is its not parenthesis that make scheme hard, 
its prefix operators. But I have no evidence to back that up with other 
than my own experience.

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

> Is the audience HtDP students/teachers, professional programmers,
> hobbyists, someone else, or all of the above?

People new to Racket, whether students or developers.

> And, if the audience includes HtDP students/teachers, would all the
> HtDP examples be revised to use P4P?

It's way too early to speculate on such things.  P4P has only existed
for a week (though, according to Jay, Honu does everything in P4P,
which means it's been dormant for years).  For now it's purely in
"highly experimental" state, though some ambitious people may be
willing to experiment with it.

>  Or would P4P be something to point to,
> like, "Hey, students have to use the academic parentheses in the student
> languages, but Racket is not just an academic (i.e., parentheses) language
> once students graduate."

No; to the contrary, I want to offer this to students.  Student code
has pretty serious visual structure problems.  The presence of
indentation sensitivity is no accident.  That's what I originally set
out to do.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

On Wed, Jul 28, 2010 at 2:31 PM, Jay McCarthy  wrote:
> At first I thought, how is this different than Honu?

I don't know anything about Honu.  As far as I can tell it's the great
undead language of the Racket world.  If Honu's already solved the
problem and is being actively used, great, I can stop!  I didn't know
Honu enforced indentation -- when did it start doing so?

-

The keywords aren't adhoc.  defar, defconst, defstruct are something
we're actively discussing.  The colons are there for reasons the
document states.  begin -> do is an intentional variation but open to
change.  elif and else have no Racket counterpart.

Ultimately, this is not purely a brain-dead macro: it is also an
exercise in syntax design (eg, indentation).

-

I now have {} enforcement for do: as well.  Re. :, do you mean that I
should ensure regular identifiers don't have trailing :'s?  I worry
that this will not play well with interoperating with Racket, which is
a desirable goal.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jos Koot]

With a good editor, like that of DrSceme, pardon me, RdRacket, I experience
no difficulty at all with parentheses. In fact I hardly see them. DrRacket
shows me the extent of a subsexpr very micely. I would have, may be, a
problem when parsing symbolic expressions lacking parenteses, unless, of
course, reading a sexpr with omission of unecessary parentheses would give
me an old fashioned parenthesized sexpr. I am not convinced, yet ...
Jos

> -Original Message-
> From: dev-boun...@racket-lang.org 
> [mailto:dev-boun...@racket-lang.org] On Behalf Of Shriram 
> Krishnamurthi
> Sent: 28 July 2010 19:45
> To: PLT Developers
> Subject: [racket-dev] P4P: A Syntax Proposal
> 
> I've been vexed for a while about parenthetical syntax: I 
> love it, appreciate what it offers, but also recognize that 
> no amount of teaching or arguing alters how people perceive 
> it.  With the switch to Racket, and our continuing interest 
> in user interface issues, I believe it is wise to consider an 
> optional alternate syntax.
> 
> I finally had a breakthrough last weekend on how to create a 
> syntax that may be more palateable without losing the essence 
> of parenthetical syntax.  As a preview, it does incorporate 
> indentation, but in a good way.  You'll see.
> 
> Feedback welcome.  The most important is whether you spot any 
> flaws regarding predictable parsing.
> 
> Here's a *non-permanent* URL where you can learn more:
> 
>   http://www.cs.brown.edu/~sk/tmp/P4P/
> 
> Shriram
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Neil Van Dyke]

Is the audience HtDP students/teachers, professional programmers, 
hobbyists, someone else, or all of the above?


And, if the audience includes HtDP students/teachers, would all the HtDP 
examples be revised to use P4P?  Or would P4P be something to point to, 
like, "Hey, students have to use the academic parentheses in the student 
languages, but Racket is not just an academic (i.e., parentheses) 
language once students graduate."


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

That did the trick -- thanks!

On Wed, Jul 28, 2010 at 2:18 PM, Jay McCarthy  wrote:
> Look up the 'paren-shape stx property.
>
> Jay
>
> On Wed, Jul 28, 2010 at 12:17 PM, Shriram Krishnamurthi  
> wrote:
>> That does sound like the right level, in that this isn't a new
>> "language" -- by design.
>>
>> I started out by trying to create a new syntax; then I realized I
>> didn't need to; then that I didn't *want* to.  By then I was locked
>> into this file structure and didn't come up for air.  I probably
>> didn't peel off enough layers.
>>
>> Before I can move forward, I still need to resolve the syntactic
>> ambiguity.  As I understand it, Racket doesn't give me enough
>> information to distinguish {...} from (...) from [...].  Is that right
>> and, if so, is there any chance that will change?  [Zodiac did that
>> <-;.]  I don't want a solution that looks like "go look in the MrEd
>> buffer for...".  I'd rather not do a reader extension for it because
>> the extra keystrokes will add up.
>>
>> Shriram
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
>
>
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://teammccarthy.org/jay
>
> "The glory of God is Intelligence" - D&C 93
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jay McCarthy]

At first I thought, how is this different than Honu?

If this isn't a reader, I don't see it being fundamentally different
from Honu. (Many of the same ideas are recreated, actually. The macro
slack term, for example, is exactly what Jon does.)

I think there is a place for a non-sexp reader like the @ reader, but
optimized for something other than text. But I don't like P4P's ad-hoc
set of special keywords like "defvar:" etc rather than a uniform rule.
If the parser has to know about these, then P4P is not extensible in
the same way as the sexp or @ readers.

A constructive suggestion: treat a trailing : as a special parser cue,
treating {s specially, taking the meaningful indentation ideas, etc.

Jay

On Wed, Jul 28, 2010 at 11:45 AM, Shriram Krishnamurthi  
wrote:
> I've been vexed for a while about parenthetical syntax: I love it,
> appreciate what it offers, but also recognize that no amount of
> teaching or arguing alters how people perceive it.  With the switch to
> Racket, and our continuing interest in user interface issues, I
> believe it is wise to consider an optional alternate syntax.
>
> I finally had a breakthrough last weekend on how to create a syntax
> that may be more palateable without losing the essence of
> parenthetical syntax.  As a preview, it does incorporate indentation,
> but in a good way.  You'll see.
>
> Feedback welcome.  The most important is whether you spot any flaws
> regarding predictable parsing.
>
> Here's a *non-permanent* URL where you can learn more:
>
>  http://www.cs.brown.edu/~sk/tmp/P4P/
>
> Shriram
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Jay McCarthy]

Look up the 'paren-shape stx property.

Jay

On Wed, Jul 28, 2010 at 12:17 PM, Shriram Krishnamurthi  
wrote:
> That does sound like the right level, in that this isn't a new
> "language" -- by design.
>
> I started out by trying to create a new syntax; then I realized I
> didn't need to; then that I didn't *want* to.  By then I was locked
> into this file structure and didn't come up for air.  I probably
> didn't peel off enough layers.
>
> Before I can move forward, I still need to resolve the syntactic
> ambiguity.  As I understand it, Racket doesn't give me enough
> information to distinguish {...} from (...) from [...].  Is that right
> and, if so, is there any chance that will change?  [Zodiac did that
> <-;.]  I don't want a solution that looks like "go look in the MrEd
> buffer for...".  I'd rather not do a reader extension for it because
> the extra keystrokes will add up.
>
> Shriram
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

That does sound like the right level, in that this isn't a new
"language" -- by design.

I started out by trying to create a new syntax; then I realized I
didn't need to; then that I didn't *want* to.  By then I was locked
into this file structure and didn't come up for air.  I probably
didn't peel off enough layers.

Before I can move forward, I still need to resolve the syntactic
ambiguity.  As I understand it, Racket doesn't give me enough
information to distinguish {...} from (...) from [...].  Is that right
and, if so, is there any chance that will change?  [Zodiac did that
<-;.]  I don't want a solution that looks like "go look in the MrEd
buffer for...".  I'd rather not do a reader extension for it because
the extra keystrokes will add up.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] P4P: A Syntax Proposal

[Robby Findler]

Sounds like a great idea to me and well worth trying at a larger scale.

One technical question: why not implement this as a reader that
converts things to the usual parenthesized versions of the program and
then, like the at-exp reader, allow people to write

  #lang p4p-exp racket

for the p4p version of 'racket', etc.

(And then start porting interesting looking files in the distribution
and leaving them ported.)

Robby

On Wed, Jul 28, 2010 at 12:45 PM, Shriram Krishnamurthi  
wrote:
> I've been vexed for a while about parenthetical syntax: I love it,
> appreciate what it offers, but also recognize that no amount of
> teaching or arguing alters how people perceive it.  With the switch to
> Racket, and our continuing interest in user interface issues, I
> believe it is wise to consider an optional alternate syntax.
>
> I finally had a breakthrough last weekend on how to create a syntax
> that may be more palateable without losing the essence of
> parenthetical syntax.  As a preview, it does incorporate indentation,
> but in a good way.  You'll see.
>
> Feedback welcome.  The most important is whether you spot any flaws
> regarding predictable parsing.
>
> Here's a *non-permanent* URL where you can learn more:
>
>  http://www.cs.brown.edu/~sk/tmp/P4P/
>
> Shriram
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] P4P: A Syntax Proposal

[Shriram Krishnamurthi]

I've been vexed for a while about parenthetical syntax: I love it,
appreciate what it offers, but also recognize that no amount of
teaching or arguing alters how people perceive it.  With the switch to
Racket, and our continuing interest in user interface issues, I
believe it is wise to consider an optional alternate syntax.

I finally had a breakthrough last weekend on how to create a syntax
that may be more palateable without losing the essence of
parenthetical syntax.  As a preview, it does incorporate indentation,
but in a good way.  You'll see.

Feedback welcome.  The most important is whether you spot any flaws
regarding predictable parsing.

Here's a *non-permanent* URL where you can learn more:

  http://www.cs.brown.edu/~sk/tmp/P4P/

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev