> My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before;
Yes, I agree he was saying that, but that doesn't mean we can't change the implementations of what we use now to actually make it easier to do accomplish this.
> another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one?
But, you could still implement car and cdr in terms on conc, so this is not really an issue. It might not be the most efficient thing, but that's sort of the benefit of macros. Expand at compile time, and avoid the overhead. So, in summary, write macros in terms of an emulated cons cell, and use conc optimized primitives elsewhere.
But, you could still implement car and cdr in terms on conc, so this is not really an issue.
It might still be an issue. The more distance there is between how code is represented and how data and lower levels of code are represented, the less fluid programming in Lisp becomes. Yes, you can translate one to the other. But the sweet spot of Lisp is the space where no such mapping is needed or it's trivial; the magic drops off pretty sharply as you leave that space. It's not obvious (to me anyway) what the effect of what we're talking about would be. Small changes can have surprisingly big impacts, and one has to include the psychology of this.
Yes, I agree he was saying that, but that doesn't mean we can't change the implementations of what we use now to actually make it easier to do accomplish this.
> another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one?
But, you could still implement car and cdr in terms on conc, so this is not really an issue. It might not be the most efficient thing, but that's sort of the benefit of macros. Expand at compile time, and avoid the overhead. So, in summary, write macros in terms of an emulated cons cell, and use conc optimized primitives elsewhere.