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 Jul 30, 2010, at 4:25 PM, Robby Findler wrote:
> Looks like it would make a nice, involved exercise if you told the
> students what the right world type should be.
It would reinforce the FSA design idea, but it will consume space.
I'll put it on my list and see how much space I need.
>
Looks like it would make a nice, involved exercise if you told the
students what the right world type should be.
Did you consider making the world be a list of keys and a posn
(inserting and removing from the list in the key handler and
"interpreting" the list of keys in the tick handler)?
Robby
I have finally taken the time to design a controller for an object that
allows the use of multiple arrow keys. Two insights: it is doable and it
is a truly insightful exercise on state machines. Most of the 'bullet'
points at the top of the program came about because I designed and explored.
B
The context of that one is also good. :)
Robby
On Fri, Jul 30, 2010 at 1:59 PM, Jay McCarthy wrote:
> "Creating a large piece of safety-critical or security-critical code
> in C or C++ is the programming equivalent of crossing an 8-lane
> freeway blindfolded."
>
> On Fri, Jul 30, 2010 at 12:39 P
"Creating a large piece of safety-critical or security-critical code
in C or C++ is the programming equivalent of crossing an 8-lane
freeway blindfolded."
On Fri, Jul 30, 2010 at 12:39 PM, Robby Findler
wrote:
> Here's parts 2:
>
> http://blog.regehr.org/archives/232
>
> and 3:
>
> http://blog.
Here's parts 2:
http://blog.regehr.org/archives/232
and 3:
http://blog.regehr.org/archives/226
and if you missed part 1, you should really check it out:
http://blog.regehr.org/archives/213
Robby
_
For list-related administrative tasks:
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
This is the final list, please see if you have any more changes --
specifically, the order is pretty much random.
--
* Changes (as part of 5.0) in the `racket' language compared to the
`scheme' language include constructor-style
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
>
20 matches
Mail list logo
