On 11-12-23 12:03 PM, Marijn Haverbeke wrote:
I'm also curious what people think are "the important parts" of unicode.
Character classification is very important, and should be in core I
think (if only to encourage people to actually use it instead of
rolling their own... badly).
Yeah. I look
> I'm also curious what people think are "the important parts" of unicode.
Character classification is very important, and should be in core I
think (if only to encourage people to actually use it instead of
rolling their own... badly).
Encodings are something people will occasionally need, but a
> Yeah. One thing that concerns me about that is that it means we lose the
> ability to write rebind-the-variable functional-style code:
Oh. You'd make this apply to irrevocable patterns as well? Or do you
intend to get rid of the restriction that let patterns are
irrevocable?
In the second case,
On 11-12-23 11:34 AM, Patrick Walton wrote:
I do agree that the action-at-a-distance is a potential problem, but experience
suggests that the Standard ML rule leads to the bad outcome less often than the
other alternatives. At this point I've tried all four alternatives
(variable-by-default, t
I do agree that the action-at-a-distance is a potential problem, but experience
suggests that the Standard ML rule leads to the bad outcome less often than the
other alternatives. At this point I've tried all four alternatives
(variable-by-default, tag-by-default, case sensitivity, and the Stand
Hi,
I've been poking around with the issue of unicode support, which I think
is very important in the language, but carries a bit of a ... tension in
terms of what we include and at-what-level of the libraries.
Namely: the canonical "unicode implementation" in the world is libicu,
in terms o
> I wasn't saying the implementation sounded freaky. I was just imagining
> looking at a 30,000 line Rust source file with large fn definitions and
> trying to figure out whether each one is a block with interesting side
> effects through the mutable closure or not.
They don't become closures. Th
I wasn't saying the implementation sounded freaky. I was just imagining
looking at a 30,000 line Rust source file with large fn definitions and
trying to figure out whether each one is a block with interesting side
effects through the mutable closure or not.
On Fri, Dec 23, 2011 at 4:06 AM, Mari
> The idea that a fn (no closure) could implicitly turn into a block (mutable
> closure) seemed freaky when I read the tutorial.
There is no actual allocation going on -- the function pointer is
paired with a null environment pointer, and that's the closure. You
pay nothing, and since a (non-closi
If I understand things right, a block has a mutable closure, while either a
lambda or a sendfn has an immutable closure?
The idea that a fn (no closure) could implicitly turn into a block (mutable
closure) seemed freaky when I read the tutorial. For immutability by
default, wouldn't a lambda or s
> Marijn's note on the wiki[1] about this says he is not a fan. Is this still
> true? Is the opposition strong or weak?
I'm still not optimistic. I think we'll want to extend pattern
matching to also handle matching against constants and maybe even
local variables. So probably the rule would end u
11 matches
Mail list logo
