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 parenthes
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 "st
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 wi
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
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 like
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 ha
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
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.
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.
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 synt
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
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 th
> 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 ne
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,
> 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
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 o
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
>
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
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
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
who
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
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
synta
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
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 lib
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 a
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
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:
+
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 th
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?)
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
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
___
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
> 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
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
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 t
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 happ
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 ha
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
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
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 entirel
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 adm
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'v
>> - 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 (a
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 li
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 bet
> 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 l
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
> 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 Fl
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 s
> 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.)
Prec
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 re
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/
arenteses, 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 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 su
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.
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
i
-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 be
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
> 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 earl
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 st
i
> 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 peop
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
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.
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 t
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
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
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 ve
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
68 matches
Mail list logo
