www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.metastrings

reply Bill Baxter <wbaxter gmail.com> writes:
Std.metastrings could use some work.

So I'm thinking to take it upon myself to make it more useful.

After asking some questions here about it previously, I got a bunch of
comments like "oh yeh I have that in my CoolTools.ctfe module".  Well,
that's kinda silly that everyone is re-inventing such things.

I'm just mentioning this here in case someone wants to stop me,  or
offer their versions of CoolTools.ctfe, or argue that it should be
std.ctfe rather than std.metastrings, or whatever.

My plan is to try to do things with an API that reflects std.string as
closely as possible, and then as CTFE gets better, just replace those
functions with aliases to the ones in std.string.  So eventually
std.metastrings should contain little more than a bunch of aliases.
But in the mean time there'll be a one-stop shop for basic
compile-time string manipulation functions.

--bb
Nov 13 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:


 I'm just mentioning this here in case someone wants to stop me,  or
 offer their versions of CoolTools.ctfe, or argue that it should be
 std.ctfe rather than std.metastrings, or whatever.


I suggest you to ask to downs too, he has done lot of such things. Using a
cleaned up part of his 'tools' (in scraps) for Phobos can be positive. Even if
some things will need to be adapted to D2 (downs has written them for D1, I
think) their purpose, name (and code) can give you a good starting point.

Bye,
bearophile
Nov 13 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Std.metastrings could use some work.
 
 So I'm thinking to take it upon myself to make it more useful.
 
 After asking some questions here about it previously, I got a bunch of
 comments like "oh yeh I have that in my CoolTools.ctfe module".  Well,
 that's kinda silly that everyone is re-inventing such things.
 
 I'm just mentioning this here in case someone wants to stop me,  or
 offer their versions of CoolTools.ctfe, or argue that it should be
 std.ctfe rather than std.metastrings, or whatever.
 
 My plan is to try to do things with an API that reflects std.string as
 closely as possible, and then as CTFE gets better, just replace those
 functions with aliases to the ones in std.string.  So eventually
 std.metastrings should contain little more than a bunch of aliases.
 But in the mean time there'll be a one-stop shop for basic
 compile-time string manipulation functions.
 
 --bb


Please have at it.

Andrei
Nov 13 2009
prev sibling next sibling parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Fri, 13 Nov 2009 22:17:21 +0200, Bill Baxter <wbaxter gmail.com> wrote:


 My plan is to try to do things with an API that reflects std.string as
 closely as possible, and then as CTFE gets better, just replace those
 functions with aliases to the ones in std.string.  So eventually
 std.metastrings should contain little more than a bunch of aliases.
 But in the mean time there'll be a one-stop shop for basic
 compile-time string manipulation functions.


Why don't we have version(CTFE) or something like that yet? Then we can  
just have two versions of code for most of std.string - one optimized for  
runtime execution, and one adhering to CTFE restrictions. That would  
remove the need to write two versions of a function which would be called  
both during compile-time and runtime (one using std.metastrings and one  
using std.string).

Also, nitpick: std.metastrings is plural but std.string is singular.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Nov 14 2009
parent Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:

 On Fri, 13 Nov 2009 22:17:21 +0200, Bill Baxter <wbaxter gmail.com> wrote:
 

 My plan is to try to do things with an API that reflects std.string as
 closely as possible, and then as CTFE gets better, just replace those
 functions with aliases to the ones in std.string.  So eventually
 std.metastrings should contain little more than a bunch of aliases.
 But in the mean time there'll be a one-stop shop for basic
 compile-time string manipulation functions.


 
 Why don't we have version(CTFE) or something like that yet? Then we can 
 just have two versions of code for most of std.string - one optimized 
 for runtime execution, and one adhering to CTFE restrictions. That would 
 remove the need to write two versions of a function which would be 
 called both during compile-time and runtime (one using std.metastrings 
 and one using std.string).


Yes, I think it's something we need. I've worked out how to do it, but 
haven't implemented it yet. There's way too much to do...

It would fit very nicely into the 'meta' proposal. EG
if (meta.ctfe) { ... } else { ... }
Nov 14 2009
prev sibling parent reply downs <default_357-line yahoo.de> writes:
Slightly modified from what you so amusingly called "my CoolTools.ctfe":

ctSlice (not to be confused with the [] array slicing functionality) "slices" a
string in two at a marker, returning the text before the marker and removing it
(and the marker) from the input text.

The ct prefix is handy for differentiating between std.metastrings and
std.string functions - one may often want to import both ..

string ctSlice(ref string what, string where) {
  auto loc = what.ctFind(where);
  if (loc == -1) {
    auto res = what;
    what = null;
    return res;
  }
  auto res = what[0 .. loc];
  what = what[loc+where.length .. $];
  return res;
}

When is this useful?

For instance, when writing a compile-time enum, you may want to use a syntax of
the form "EnumName: Entries"

In that case, you could write `string name = input.ctSlice(":"); '
Nov 14 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sat, Nov 14, 2009 at 10:16 AM, downs <default_357-line yahoo.de> wrote:

 Slightly modified from what you so amusingly called "my CoolTools.ctfe":

 ctSlice (not to be confused with the [] array slicing functionality) "sli=


ces" a string in two at a marker, returning the text before the marker and =
removing it (and the marker) from the input text.

 The ct prefix is handy for differentiating between std.metastrings and st=


d.string functions - one may often want to import both ..

Yeh, I agree some diffentiator is good.  std.metastrings started off
with a capital letter convention to differentiate.  I'm not sure which
is better.


 string ctSlice(ref string what, string where) {
 =A0auto loc =3D what.ctFind(where);
 =A0if (loc =3D=3D -1) {
 =A0 =A0auto res =3D what;
 =A0 =A0what =3D null;
 =A0 =A0return res;
 =A0}
 =A0auto res =3D what[0 .. loc];
 =A0what =3D what[loc+where.length .. $];
 =A0return res;
 }

 When is this useful?

 For instance, when writing a compile-time enum, you may want to use a syn=


tax of the form "EnumName: Entries"

 In that case, you could write `string name =3D input.ctSlice(":"); '


That's nice.
I would probably call that something like "ctZapToChar", in honor of
the same function in Emacs. :-)
Slice is a very confusing name for it.

So is your code free game for stealing from for std.metastring?
(meaning whatever I borrowed would be re-licensed under Boost)

--bb
Nov 14 2009
parent downs <default_357-line yahoo.de> writes:
Bill Baxter wrote:

 On Sat, Nov 14, 2009 at 10:16 AM, downs <default_357-line yahoo.de> wrote:

 Slightly modified from what you so amusingly called "my CoolTools.ctfe":

 ctSlice (not to be confused with the [] array slicing functionality) "slices"
a string in two at a marker, returning the text before the marker and removing
it (and the marker) from the input text.

 The ct prefix is handy for differentiating between std.metastrings and
std.string functions - one may often want to import both ..


 
 Yeh, I agree some diffentiator is good.  std.metastrings started off
 with a capital letter convention to differentiate.  I'm not sure which
 is better.
 

 string ctSlice(ref string what, string where) {
  auto loc = what.ctFind(where);
  if (loc == -1) {
    auto res = what;
    what = null;
    return res;
  }
  auto res = what[0 .. loc];
  what = what[loc+where.length .. $];
  return res;
 }

 When is this useful?

 For instance, when writing a compile-time enum, you may want to use a syntax
of the form "EnumName: Entries"

 In that case, you could write `string name = input.ctSlice(":"); '


 
 That's nice.
 I would probably call that something like "ctZapToChar", in honor of
 the same function in Emacs. :-)
 Slice is a very confusing name for it.
 
 So is your code free game for stealing from for std.metastring?
 (meaning whatever I borrowed would be re-licensed under Boost)
 
 --bb


Feel free. :D

(yes this constitutes a full license to redistribute)
Nov 14 2009