digitalmars.D.announce - Vote started for std.uni
- Jesse Phillips (2/2) May 19 2013 Please cast your vote for std.uni at:
- deadalnix (6/8) May 20 2013 Overall it looks great. I have one question l is it possible to
- Dmitry Olshansky (31/40) May 20 2013 At compile-time? The short answer is it should be possible but not quite...
- deadalnix (10/35) May 20 2013 I understand. To me a caching compiler is the solution here, but
- eles (3/7) May 20 2013 I support renaming to std.unicode;
- captaindet (2/8) May 21 2013 +1
- Jesse Phillips (3/11) May 20 2013 Please place this in the vote thread, or it will not be counted
Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjfllehzg forum.dlang.org
May 19 2013
On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjfllehzg forum.dlang.orgOverall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?
May 20 2013
20-May-2013 12:15, deadalnix пишет:On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4; --- Error: CTFE internal error: unsupported assignment this = p uni.d(1841): called from here: this.data.opAssign((Uint24Array!(GcPolicy) __ctmp6762 = 0; , __ctmp6762).this(flattened)) uni.d(6742): called from here: (InversionList!(GcPolicy) __ctmp6477 = 0; , __ctmp6477).this(decompressIntervals(compressed)) --- So I forgot to reduce a bug it seems (or maybe I filed it). Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source. This is actualy one of things I'd love to push as a separate feature Phobos-wide: serialization of objects to CTFE-able/mixin-able source code. Some of these done in std.uni weren't clean enough to fit into a public interface.Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjfllehzg forum.dlang.orgOverall it looks great. I have one question l is it possible to build tries at runtime using CTFE ?Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d. -- Dmitry Olshansky
May 20 2013
On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:20-May-2013 12:15, deadalnix пишет:As long as it is doable, that sound good to me.On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4;Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjfllehzg forum.dlang.orgOverall it looks great. I have one question l is it possible to build tries at runtime using CTFE ?Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source.I understand. To me a caching compiler is the solution here, but that is kind of off topic.I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d.The problem wth that kind of naming convention is that names do not convey as much meaning. This can be an issue as the library get larger and larger, because you got to remember every single name and can't rely too much on autocompletion. uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
May 20 2013
On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote:On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:I support renaming to std.unicode; In the long run, std.uni is just unexpressive.20-May-2013 12:15, deadalnix пишет:uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
May 20 2013
captaindet <2krnk gmx.net> On 2013-05-20 22:58, eles wrote:On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote:+1On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote:I support renaming to std.unicode; In the long run, std.uni is just unexpressive.20-May-2013 12:15, deadalnix пишет:uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
May 21 2013
On Monday, 20 May 2013 at 08:15:48 UTC, deadalnix wrote:On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote:Please place this in the vote thread, or it will not be counted when I get to tallying.Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjfllehzg forum.dlang.orgOverall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?
May 20 2013