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

2010-07-31 Thread Jens Axel Søgaard
2010/7/31 Eli Barzilay e...@barzilay.org:

 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

2010-07-30 Thread Robby Findler
On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay e...@barzilay.org 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

2010-07-30 Thread 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

2010-07-30 Thread John Clements

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

 On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay e...@barzilay.org 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

2010-07-30 Thread 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: e with: id e w/ id bound
--
(filter e (lambda (id) e w/ id bound))

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

2010-07-30 Thread 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 e...@barzilay.org wrote:
 On Jul 30, Robby Findler wrote:
 On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay e...@barzilay.org 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

2010-07-30 Thread 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 e...@barzilay.org wrote:
 On Jul 30, Robby Findler wrote:
 On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay e...@barzilay.org 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

2010-07-30 Thread Joe Marshall
On Fri, Jul 30, 2010 at 5:30 AM, Shriram Krishnamurthi s...@cs.brown.edu 
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

[racket-dev] P4P: A Syntax Proposal

2010-07-30 Thread Guillaume Marceau
On Fri, Jul 30, 2010 at 10:52 AM, Matthias Felleisen
matth...@ccs.neu.edu 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

2010-07-30 Thread 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


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

2010-07-29 Thread 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

2010-07-29 Thread Michael Sperber

Shriram Krishnamurthi s...@cs.brown.edu 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

2010-07-29 Thread 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

2010-07-29 Thread 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

2010-07-29 Thread Everett Morse

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

 On Thu, Jul 29, 2010 at 9:12 AM, Michael Sperber
 sper...@deinprogramm.de 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

2010-07-29 Thread 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

2010-07-29 Thread 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

2010-07-29 Thread Shriram Krishnamurthi
I disagree.  I think parens are synecdoche.

Shriram

On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
ro...@eecs.northwestern.edu 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 jmarsh...@alum.mit.edu wrote:
 On Wed, Jul 28, 2010 at 3:06 PM, Everett we...@unoc.net 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

2010-07-29 Thread 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 s...@cs.brown.edu 
wrote:
 I disagree.  I think parens are synecdoche.

 Shriram

 On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
 ro...@eecs.northwestern.edu 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 jmarsh...@alum.mit.edu 
 wrote:
 On Wed, Jul 28, 2010 at 3:06 PM, Everett we...@unoc.net 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

2010-07-29 Thread 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
ro...@eecs.northwestern.edu 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 s...@cs.brown.edu 
 wrote:
 I disagree.  I think parens are synecdoche.

 Shriram

 On Thu, Jul 29, 2010 at 1:28 PM, Robby Findler
 ro...@eecs.northwestern.edu 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 jmarsh...@alum.mit.edu 
 wrote:
 On Wed, Jul 28, 2010 at 3:06 PM, Everett we...@unoc.net 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

2010-07-29 Thread 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


[racket-dev] P4P: A Syntax Proposal

2010-07-28 Thread 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


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

2010-07-28 Thread 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 s...@cs.brown.edu 
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

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

2010-07-28 Thread 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

2010-07-28 Thread Jay McCarthy
Look up the 'paren-shape stx property.

Jay

On Wed, Jul 28, 2010 at 12:17 PM, Shriram Krishnamurthi s...@cs.brown.edu 
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 j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

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

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

2010-07-28 Thread 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 s...@cs.brown.edu 
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 j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

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

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

2010-07-28 Thread Shriram Krishnamurthi
That did the trick -- thanks!

On Wed, Jul 28, 2010 at 2:18 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 Look up the 'paren-shape stx property.

 Jay

 On Wed, Jul 28, 2010 at 12:17 PM, Shriram Krishnamurthi s...@cs.brown.edu 
 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 j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://teammccarthy.org/jay

 The glory of God is Intelligence - DC 93

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


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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread Shriram Krishnamurthi
On Wed, Jul 28, 2010 at 2:31 PM, Jay McCarthy jay.mccar...@gmail.com 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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread 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 n...@neilvandyke.org
To: Jos Koot jos.k...@telefonica.net
Cc: PLT Developers d...@lists.racket-lang.org
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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread 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

2010-07-28 Thread 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