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