Re: [racket-dev] P4P: A Syntax Proposal
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
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
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
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
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
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
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
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
Re: [racket-dev] P4P: A Syntax Proposal
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
Just a note, it does look not entirely unsimilar to: http://srfi.schemers.org/srfi-49/srfi-49.html (For a good chuckle, look at the discussion archive.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Shriram Krishnamurthi 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
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
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
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
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
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
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
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
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
On Thu, 2010-07-29 at 15:37 -0400, Shriram Krishnamurthi wrote:
Quick addendum:
Infix notation can be achieved unambiguously if you use LL(1) with
backtracking instead of just LL(1) by accepting expressions in the form
(a b c) that become b(a, c). This is unambiguous only if you do not
allow including useless parenthesis around expressions
This would not be a good idea. Students are taught that infix goes
hand-in-hand with useless parens -- if in doubt, add parentheses, you
can add as many as you want. So giving them infix syntax but NOT
permitting useless parens would fry their circuits.
Shriram
I thought it was a clever idea because it forces parens around each
individual use, so the programmer has to think of associativity and
precedence, but allows a more readable representation. So the d/dx
example becomes:
deffun: d/dx(f) =
defvar: delta = 0.001
fun: (x) in
((f((x + delta)) - f(x)) / delta)
Which can be understood easier than the prefix version but avoids all
the negatives of a complete infix notation.
The same could, of course, be accomplished with a macro (in a op b) -
(op a b). But in P4P that would end up looking like in(1, +, 2) which
isn't quite as nice. Maybe yet another keyword for in:(1 + 2).
deffun: d/dx(f) =
defvar: delta = 0.001
fun: (x) in
in:(in:( f( in:(x + delta) ) - f(x)) / delta) ; not as pretty...
Since your target use if for students, I could be convinced that infix
doesn't belong. But both students and experienced (non-LISP)
programmers will complain about the prefix math. (And prefix comparison
operators.)
BTW, any binary operation that expresses a relationship between first
and second operands could be clarified by writing it in infix. So a
function application match(string, pattern) could be (string match
pattern). So allowing infix does not destroy the understanding that +
is not any more special than any other function.
Also, if P4P is dependent on keywords like if: elif: etc. then macros
are crippled unless they can also make use of key words. I believe Honu
somehow makes structural keywords unspecial, but requires redefining the
standard library (making the Honu language in addition to
H-Expressions). An idea I had, but haven't worked the kinks out of yet,
was something like:
if( cond ) then: {
expr-true
} else: {
expr-false
}
--
(if cond #:then expr-true #:else expr-false)
which also requires redefining the standard library.
Other examples:
filter( lst ) with:(elem) { odd?(elem) }
--
(filer lst #:with (lambda (elem) (odd? elem)))
and
switch(val)
case:(hello) { ... }
else: { ... }
--
(cases val #:case (lamda (hello) ...) #:else ...)
which would require the macro look in the param list of the case's
lambda to find the pattern to match instead of in groupings of parens.
The switch example shows one more instance where someone will want to
define a structure that you haven't thought of. I believe you said cond
will just have to be a bunch of if/elif. But someone will still want to
implement cond. If you can't handle creating new structures in your
syntax then P4P will only be useful to students. It won't help pull
parenthesis-haters into the Racket camp (unless you implement all the
structures they could wish for in your parser, since
non-schemers/lispers aren't used to creating new syntaxes with macros).
-Everett
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
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
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
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
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
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
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
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
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
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
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
@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
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
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
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
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
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
- 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
