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
On Tue, Oct 28, 2008 at 12:39 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> 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 e
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 s
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 notatio
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 fun
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
Specifically, in the tail-calling cases:
g(); break;
has the unintuitive behavior of *first* breaking out of the
switch-block and *then* evaluating g().
Since the difference cannot be observed (other than through growth of
the control stack), I don't see that it really matters which is do
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
>> 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 object dispatcher
concept, to try and come up
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.
instead of
switch(type) {
case "big":
//do something big
break
On Oct 27, 2008, at 8:21 AM, Maciej Stachowiak wrote:
As I say, I'm not really in favor of this semantics. I think it's
too complicated and bifurcates the meaning of `break'. The fact is
if you write:
case 1:
if (p()) {
f();
g();
break;
}
On Oct 27, 2008, at 8:21 AM, Maciej Stachowiak wrote:
A more functional multiple-case dispatch form would be like
Scheme's `cond' or ML/Haskell `case'. God, we need macros.
ECMAScript's switch is sort of halfway between Scheme cond and C
switch. Personally I think fall through and explicit
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
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 attri
Maciej Stachowiak wrote:
> On Oct 20, 2008, at 2:23 PM, Dave Herman wrote:
>
>> I doubt there's any clean way to fit tail positions into a switch
>> statement, since it works by jumping out of the statement. I'll have
>> to look closer at the semantics of the completion value of a switch
>> stat
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 i
Maciej Stachowiak wrote:
>
> 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;
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:
>> ...
>> }
>> }
>
> 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 swit
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 becaus
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(
Dave Herman wrote:
>> 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.
OK. You just stated that it's "a given and not relevant" that the f
> 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 be
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 s
> 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 to ha
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)
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 cod
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
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
>> 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 traditio
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
31 matches
Mail list logo
