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
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
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 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
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
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
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
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
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
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
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
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?
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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
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
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
@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
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
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
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
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
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
- 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
37 matches
Mail list logo
