[erlang-questions] string:lexeme/s2 - an old man's rant

Thu May 9 12:52:11 CEST 2019

On Wed, 08 May 2019 23:18:17 +0900
zxq9@REDACTED wrote:

> On 2019年5月8日水曜日 10時53分25秒 JST Richard O'Keefe
> wrote:
> > Again for what it's worth, Unicode defines an algorithm
> > for breaking text into word( token)s.
> I don't really mind the term "lexeme",

What if someone wants to break their "text" into
chippy-choppy-parts and neither words, nor tokens, nor
lexemes? and even if their parts could be called one of
these in some context they do not want to know?

> If we needed a new function, it seems the name
> "tokenize/2" might have been an easier mental adjustment.

Oh, the dark side is not stronger, but easier, more
seductive ... In a functional language I want names
describe the result not the action producing that result.
Imperative send() and fwrite() are fine because they are no
functions (mapping args to result) but mere procedures that
happen to return something more or less useful. No wonder
that send() is Prolog's exclamation mark: no backtracking
across a message sent.

> But anyway, naming things is hard

Actually it is *much* too easy, but finding *good*
names, good in all, or at least the most important
contexts ...
But I am sure that is what you mean.

> unicode enhancements are a big enough deal that I could
> *almost* care less what they are called.

As I have buried in my much ignored "Help" posting:
The complexity saved in the small, unimportant (each on its
own) but numerous details frees capacity for complexity on
the higher levels. So "almost" could be too little ...

> That said, who isn't going to open a new language's
> string lib and expect to find things called "split"

*I* do not want other languages in Erlang, lest someone
says "Hej, look at this great PHP lib ...". Of course,
Erlang cannot be a completely new kind of wheel, but I
wonder whether it is running faster than it can
without stumbling, recently, unnecessarily(?) trying to
catch up to something ...



Reasonable is that which cannot be criticised reasonably.

More information about the erlang-questions mailing list