Back to Questions
6.7k
views3
comments
String.split using string-list of separators
f#

I was using the Microsoft.FSharp.Core.String.split to create a list.

I wanted to replace the separator char list with a string list. I found no overload that did this. (There is a split method on the .NET string class that takes a string list (array), but I believe it's an instance method.)

Have I missed something?

If not, is a string list separator planned for FSharp?

.

It's entirely reasonable to use the instance methods on String objects and the static methods in System.String. You can also just define a new String module with the additional function (here called 'splits').

1
2
3
4
5

#light
module String = 
    let splits (c : string list) = 
      let ca = CompatArray.of_list c in 
      fun (s:string) -> CompatArray.to_list(s.Split(ca, System.StringSplitOptions.RemoveEmptyEntries))

The F# String module has a somewhat funny status: we strongly considered moving it to the Compatibility.OCaml namespace in mllib.dll. However we didn't, because although there's little value in trying to duplicate the functionality in System.String and System.Text, there is still value in having a consistent set of functions of String, List, Array, etc. etc. (e.g. Strng.map)

Regards

don

By on 4/26/2007 6:09 AM ()

Thanks Don. As usual your replies are valuable and thought provoking.

I've been looking for a language that works as I expect it to. It's pretty risky spending time with a research language, but I'm so browned off with the OO languages, that I decided to spend enough time to evaluate FSharp seriously. (I now associate the OO languages with obstacles to thinking and probable brain atrophy.)

With your reply, a different approach than I originally envisaged comes into focus.

That is: a language more tailored to what I want. (So I want string splitters to be a mix of character, string and regular expression, I do it. So I don't find the naming to my taste I can change it...)

I've been leery of thinking like that in the past.

(There's a few issues like: 1) Testing the "language customisation" each time the base language is revved. (Need to get around the GAC to achieve a smooth changeover.) 2) The ongoing fear that the language will die, a la Mondrian. 3) Updating integrated documentation...)

I'm still learning the language, but this shift of viewpoint has promise for addressing some concerns.

By on 4/26/2007 2:51 PM ()

That's good.

I thought I'd clarify my first response just in case people want to know what's going on. F# treats modules differently to many other ML-like languages. In particular, if you have two modules called String in scope, then identifier resolution of long paths such as "String.split" looks through the various modules in the environment addressed by this name in order (the most recently introduced gets searched first, where modules are introduced by "open" on namesapces, module abbreviations and module definitions).

This lets you define what appears to be a "fragment" of the module String in your own library, open the library, and viola, you've got the appearance of having extended the standard library module (of course you haven't really extended the library module: you've just defined your own fragment which can be addressed in a way consistent with how the standard library module is addressed).

This technique is obviously very valuable for customizing the set of functions provided in the standard library.

Note the resolution of values in modules is performed solely by name, and not by type: there is no overloading of values in F#, only overloading of members.

Some may ask "If you can extend modules in this way, then why not classes?" At some point we also plan to support a version of extension methods compatible with those used by C#, which will indeed give us a form of adhoc extension for classes and the OO "." notation on values.

Regards,

don

By on 4/26/2007 3:25 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper