Breton Slivka wrote:
[...]
var dispatch = {
1: lambda () {
p() ? f(), g() : dispatch[2]();
},
I'm nitpicking, but this is invalid syntax -- due to the relative
precedence of comma and ?:, it will be parsed as:
(p() ? f()), (g() : dispatch[2]());
You want something
On Oct 27, 2008, at 11:28 PM, Breton Slivka wrote:
I would argue it. You can either equivalently consider the fall
through to
be a jump, or say it behaves as if the code of case 2
as if the code of case 2 were duplicated into case 1
- Maciej
I had a go at combining that concept with my
On Oct 28, 2008, at 12:18 PM, Maciej Stachowiak wrote:
On Oct 27, 2008, at 11:28 PM, Breton Slivka wrote:
I had a go at combining that concept with my object dispatcher
concept, to try and come up with an example of a reasonable transform
of a switch statement to a structure with equivalent
On Mon, Oct 27, 2008 at 2:34 PM, Breton Slivka [EMAIL PROTECTED] wrote:
I don't know if anyone will find this relevant or useful, but in my
personal code, I have changed over to completely avoiding the switch
statement altogether, in favor of primarily using objects with
subscript notation.
On Oct 28, 2008, at 12:46 PM, Peter Michaux wrote:
I do roughly the same thing. Using an object is faster than switch
also, as far as I recall doing some tests. The speed of switch seems
to be the same speed as if-else if-else if-...-else.
It really depends on what you are doing. At least
On Oct 28, 2008, at 2:00 PM, Mark S. Miller wrote:
Hopefully Map will not reproduce this insanity, and so be too well
behaved to use directly in a desugaring of switch.
I don't propose to desugar switch, but yes: default Map should use
identity (eq), not ===.
/be
Maciej Stachowiak wrote:
You could probably define a rigorous transform to apply to a swtich()
statement that turns it into a series of if / else clauses (possibly
duplicating later cases if there is no break) and apply the usual if
rule to that transform to get case statements into the
On Oct 27, 2008, at 6:46 AM, Dave Herman wrote:
Maciej Stachowiak wrote:
You could probably define a rigorous transform to apply to a
swtich() statement that turns it into a series of if / else clauses
(possibly duplicating later cases if there is no break) and apply
the usual if rule to
On Oct 21, 2008, at 6:14 PM, Waldemar Horwat wrote:
Maciej Stachowiak wrote:
I don't think you can represent tail position in a switch statement
with your attribute grammar notion, but it's clear to me that the
statement immediately before a break statement, or else the last
statement in
On Oct 20, 2008, at 2:23 PM, Dave Herman wrote:
Yes, that's what I was referring to earlier. Do you now understand
my
mail from 10/17/2008 12:39?
You mean these examples?
lambda h(x) {
switch (x) {
case 1:
g();
break;
case 2:
...
}
}
I doubt there's any clean
Dave Herman wrote:
Do you see where I'm going with this? It's a pretty natural idea. The
branches of an if-statement can be in tail position because they are the
last thing produced by the if-statement. Some things like loop forms and
switch won't be able to contain tail positions because
Yes, that's what I was referring to earlier. Do you now understand my
mail from 10/17/2008 12:39?
You mean these examples?
lambda h(x) {
switch (x) {
case 1:
g();
break;
case 2:
...
}
}
I doubt there's any clean way to fit tail positions into a switch
Dave Herman wrote:
What is your point? To write a recursive factorial I'd write either:
lambda f(x) {
if (x == 0)
1;
else
f(x - 1);
}
or:
function f(x) {
if (x == 0)
return 1;
else
return f(x - 1);
}
Right, good, so far we're on the same page.
Either one is subject
What you appear to be saying is that wrapping the call to g()
inside another statement indicates that it will not be tail-recursive.
No, that's not what I'm saying-- that's a given and not relevant.
What I'm trying to say is that trying to make return into a
tail-calling form is clunky
No, I must have misunderstood what you meant by wrapping the call to
g() inside another statement -- I thought you were referring to
wrapping it in a context such as
{ -- ; stmt; }
which would obviously not be a tail position. But this:
lambda f(x) {
if (x == 0)
1;
else
f(x -
Dave Herman wrote:
I don't see enough of a benefit to warrant inclusion of a new lambda
concept. It's just another way of doing what local functions can do.
As I see it, the major benefits of `lambda' are
a) introducing a low-level and compositional primitive that is useful
for code
b) creating a clearer place in the language syntax to enforce tail
calling by eliminating `return'
I don't understand what you mean in point b.
Consider two different syntaxes for a function performing a tail call:
lambda(x) { f(x) }
function(x) { return f(x) }
The traditional
On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote:
var: Not an issue if you're not using var inside the lambda. Code
generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not using the arguments
array. If a code generator is updated for
On Thu, Oct 16, 2008 at 3:04 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote:
var: Not an issue if you're not using var inside the lambda. Code
generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not
Brendan Eich wrote:
On Oct 16, 2008, at 1:55 PM, Waldemar Horwat wrote:
var: Not an issue if you're not using var inside the lambda. Code
generation that wants to use lambda would use var why?
arguments: Again, not an issue if you're not using the arguments
array. If a code generator
Dave Herman wrote:
b) creating a clearer place in the language syntax to enforce tail
calling by eliminating `return'
I don't understand what you mean in point b.
Consider two different syntaxes for a function performing a tail call:
lambda(x) { f(x) }
function(x) { return f(x)
21 matches
Mail list logo
