Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #11817 > unrolled thread

Re: Resources to learn common lisp?

Back to article view | Back to comp.lang.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-24 19:38 +0800
    Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-24 12:22 +0000
      Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-24 21:04 +0800
        Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-24 13:18 +0000
          Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-24 22:16 +0800
            Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-24 20:10 +0000
              Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-25 10:34 +0800
          Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-08-24 17:10 -0700
            Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-25 10:41 +0800
            Re: Resources to learn common lisp? tfb <tfb@work.it.out> - 2026-08-25 09:22 +0000
              Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-08-25 22:13 -0700
                Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-26 15:43 -0300
                  Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-08-26 18:23 -0700
                    Re: Resources to learn common lisp? Anton Antimo <anton@safunu.org> - 2026-08-28 17:29 -0300
                  Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-08-27 10:17 +0000
                    Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-08-27 10:47 +0000
                      Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:49 +0800
                        Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 10:25 +0000
                      Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 11:05 +0800
                        Re: Resources to learn common lisp? red floyd <no.spam.here@its.invalid> - 2026-09-17 21:43 -0700
                        Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 10:28 +0000
                          Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 21:33 +0800
                            Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 13:51 +0000
                            Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 14:23 +0000
                              Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 15:18 +0000
                                Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 00:07 +0800
                                  Resources to learn Japanese (was: Resources to learn common lisp?) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 16:52 +0000
                        Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-18 15:11 +0000
                          Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 15:25 +0000
                            Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-18 15:49 +0000
                              Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 16:05 +0000
                                Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-19 08:29 +0000
                                  Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 16:50 +0800
                              Re: Resources to learn common lisp? David Brown <david.brown@hesbynett.no> - 2026-09-18 18:18 +0200
                                Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 00:35 +0800
                            Why no string switch? (was: Resources to learn common lisp?) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-19 12:46 +0000
                              Re: Why no string switch? (was: Resources to learn common lisp?) boltar@caprica.universe - 2026-09-19 14:47 +0000
                          Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 23:39 +0800

Page 2 of 2 — ← Prev page 1 [2]

#11873

"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>ular expression to match ' only if it's inside a word?  Do we want to
>account for Unicode single curly quotes too?

  "::std::regex" was introduced in C++11 (2011), but due to
  performance problems, it's scheduled to be deprecated.

Newsgroups: comp.lang.misc,comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#11874

On 18/09/2026 6:28 PM, Stefan Ram wrote:
> "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>> Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>> ular expression to match ' only if it's inside a word?  Do we want to
>> account for Unicode single curly quotes too?
> 
>    "::std::regex" was introduced in C++11 (2011), but due to
>    performance problems, it's scheduled to be deprecated.
> 
> Newsgroups: comp.lang.misc,comp.lang.c++
> 
> 

Dear Stefan,

Well, in my defense, I haven't used much of C++ since C++98 -- by that I
mean the standard -- since most C++ A.P.Is. are usable with roughly that
knowledge.  I have Meyers' /Effective Modern C++/ on my shelf, but it's
still in my to-read-in-the-near-future pile; thanks to tsundoku.

I also have Stroustrup's 4th edition, but I'm not sure it's worth read-
ing to catch up on the latest?  What do you think?

Now, on the subject of regular expressions, we are now in a quandary, do
we try to fix your word counting program with std::regex, and have it be
uncompilable in the near future, or do we just use PCRE2 and have it be
compilable forever?

I use the word /try/ here because I'm not offhand sure a good word
counting program can be done with strictly a regular expression, and
I am in no hurry to adopt John Levin's [1] for this purpose, and use
L.A.R.L.  I'm leaving off comp.compilers because my Usenet provider
seems to have trouble with posts to moderated Usenet groups, and I
haven't emailed them about it yet; plus this is probably a bit too
simple to bother the compiler experts about, now that I think about
it for the second time.

I am however willing to attempt to use PCRE2 in a C++ program over the
weekend so let's see what happens, and if I have the time for such an
adventure and so forth; no promises.  I mean, compiling PCRE2 with MSVC
can't be that hard, can it?


Best wishes, and happy C++!

[1] The one in the book /Flex & Bison/.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#11875

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>I also have Stroustrup's 4th edition, but I'm not sure it's worth read-
>ing to catch up on the latest?  What do you think?

  "The C++ Programming Language", fourth edition is excellent to catch
  up on C++11, but we are approaching C++26 now and a lot has changed. 

  You could read the working draft N5046 as of 2026-05-12, but it's a
  bit technical. C++ is moving too fast currently for textbook authors 
  to keep up, so maybe try websites like cppreference!

  The chatbot's comment:

| The transition "but it's a bit technical" is a bit of an
| understatement - the ISO working draft is famously dry and
| notoriously difficult to read for general learning.

  .

[toc] | [prev] | [next] | [standalone]

#11876

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>I use the word /try/ here because I'm not offhand sure a good word
>counting program can be done with strictly a regular expression,

  During this thread I did not think about it as a real
  application, but just as a example for programming. But if
  you ask me about it, the most important thing for a really
  good word-counting program is one's definition of "word".

[toc] | [prev] | [next] | [standalone]

#11878

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>>I use the word /try/ here because I'm not offhand sure a good word
>>counting program can be done with strictly a regular expression,
>During this thread I did not think about it as a real
>application, but just as a example for programming. But if
>you ask me about it, the most important thing for a really
>good word-counting program is one's definition of "word".

  For one example, I wrote a program in 2020 to count the fre-
  quencies of Japanese "words", where I had my program figure
  out which characters go together by itself using something
  that vaguely resembles byte-pair encoding (BPE), but I came 
  up with it myself before I ever heard of BPE.

  Japanese words are usually not separated by spaces. So, my
  program just observes which combinations of characters appear
  most frequently in my collection of Japanese texts, but also
  can deal with words that appear both separated from other words
  and also as parts of other words. For example, below both "ああ"
  and "あ" are listed, and the 2*32232 occurences of "あ" in "ああ"
  are not counted again to get the 22929 occurences of "あ".

  These are "words" by the definition of my program - which might
  not agree with other definitions.

  So, now you know which "words" you should learn first because
  they are most common - from the output of my program (start):

  It says, "Hai" ("yes") is the most common Japanese word! Readers
  might be surprised by "ああ" - this appears often in the spoken
  language I was interested in, but rarely in formal texts.

  And we see that the few kanji I know ("何", "私", and "今") are
  indeed very common! Again the 15591 hits of "何" in isolation
  are counted only when its not part of the "何か", "何で", and
  "何だ", which are listed and counted separately. And this also
  applies to longer sequences correspondingly.

"はい" ×67739 ↔2 –  HA  I 
"あっ" ×51279 ↔2 –  A  SMALL-TU 
"うん" ×38420 ↔2 –  U  N 
"えっ" ×37268 ↔2 –  E  SMALL-TU 
"いや" ×32336 ↔2 –  I  YA 
"ああ" ×32232 ↔2 –  A  A 
"でも" ×29729 ↔2 –  DE  MO 
"もう" ×23096 ↔2 –  MO  U 
"あ" ×22929 ↔1 –  A 
"じゃあ" ×20123 ↔3 –  ZI  SMALL-YA  A 
"ちょっと" ×19575 ↔4 –  TI  SMALL-YO  SMALL-TU  TO 
"あの" ×18596 ↔2 –  A  NO 
"え" ×16755 ↔1 –  E 
"ん" ×16391 ↔1 –  N 
"これ" ×16078 ↔2 –  KO  RE 
"何" ×15591 ↔1 – X-4F55 
"私" ×14642 ↔1 – X-79C1 
"だから" ×14125 ↔3 –  DA  KA  RA 
"おい" ×13855 ↔2 –  O  I 
"まあ" ×13307 ↔2 –  MA  A 
"今" ×12493 ↔1 – X-4ECA 
"すいません" ×11940 ↔5 –  SU  I  MA  SE  N 
"私は" ×11247 ↔2 – X-79C1  HA 
"ええ" ×11237 ↔2 –  E  E 
"何か" ×10606 ↔2 – X-4F55  KA 
"お前" ×10569 ↔2 –  O X-524D 
"それは" ×10475 ↔3 –  SO  RE  HA 
"ありがとう" ×10469 ↔5 –  A  RI  GA  TO  U 
"そう" ×9965 ↔2 –  SO  U 
"ねえ" ×9752 ↔2 –  NE  E 
"あれ" ×9180 ↔2 –  A  RE 
"どうぞ" ×8971 ↔3 –  DO  U  ZO 
"ほら" ×8948 ↔2 –  HO  RA 
"何で" ×8822 ↔2 – X-4F55  DE 
"ありがとうございます" ×8571 ↔10 –  A  RI  GA  TO  U  GO  ZA  I  MA  SU 
"あぁ" ×8396 ↔2 –  A  SMALL-A 
"お願いします" ×7552 ↔6 –  O X-9858  I  SI  MA  SU 
"俺" ×7515 ↔1 – X-4FFA 
"また" ×7467 ↔2 –  MA  TA 
"で" ×7283 ↔1 –  DE 
"よし" ×7214 ↔2 –  YO  SI 
"これは" ×7143 ↔3 –  KO  RE  HA 
"いえ" ×7052 ↔2 –  I  E 
"はぁ" ×7008 ↔2 –  HA  SMALL-A 
"どうして" ×6943 ↔4 –  DO  U  SI  TE 
"まだ" ×6851 ↔2 –  MA  DA 
"大丈夫" ×6838 ↔3 – X-5927 X-4E08 X-592B 
"それ" ×6710 ↔2 –  SO  RE 
"俺は" ×6630 ↔2 – X-4FFA  HA 
"って" ×6593 ↔2 –  SMALL-TU  TE 
"一同" ×6477 ↔2 – X-4E00 X-540C 
"だって" ×6413 ↔3 –  DA  SMALL-TU  TE 
"ごめん" ×6407 ↔3 –  GO  ME  N 
"やっぱり" ×6314 ↔4 –  YA  SMALL-TU  PA  RI 
"みんな" ×6033 ↔3 –  MI  N  NA 
"先生" ×5932 ↔2 – X-5148 X-751F 
"えッ" ×5932 ↔2 –  E  SMALL-TU 
"しかし" ×5825 ↔3 –  SI  KA  SI 
"い" ×5813 ↔1 –  I 
"それで" ×5798 ↔3 –  SO  RE  DE 
"そして" ×5790 ↔3 –  SO  SI  TE 
"う" ×5629 ↔1 –  U 
"はあ" ×5624 ↔2 –  HA  A 
"どうも" ×5535 ↔3 –  DO  U  MO 
"は" ×5511 ↔1 –  HA 
"では" ×5275 ↔2 –  DE  HA 
"あッ" ×5256 ↔2 –  A  SMALL-TU 
"さあ" ×5123 ↔2 –  SA  A 
"ごめんなさい" ×4997 ↔6 –  GO  ME  N  NA  SA  I 
"今日は" ×4907 ↔3 – X-4ECA X-65E5  HA 
"そんな" ×4819 ↔3 –  SO  N  NA 
"はっ" ×4805 ↔2 –  HA  SMALL-TU 
"それが" ×4802 ↔3 –  SO  RE  GA 
"すみません" ×4755 ↔5 –  SU  MI  MA  SE  N 
"まさか" ×4616 ↔3 –  MA  SA  KA 
"失礼します" ×4494 ↔5 – X-5931 X-793C  SI  MA  SU 
"そうか" ×4428 ↔3 –  SO  U  KA 
"何だ" ×4237 ↔2 – X-4F55  DA 
. . .

Newsgroups: comp.lang.misc

[toc] | [prev] | [next] | [standalone]

#11883

On 9/18/2026 11:18 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>>> I use the word /try/ here because I'm not offhand sure a good word
>>> counting program can be done with strictly a regular expression,
>> During this thread I did not think about it as a real
>> application, but just as a example for programming. But if
>> you ask me about it, the most important thing for a really
>> good word-counting program is one's definition of "word".
> 
>    For one example, I wrote a program in 2020 to count the fre-
>    quencies of Japanese "words", where I had my program figure
>    out which characters go together by itself using something
>    that vaguely resembles byte-pair encoding (BPE), but I came
>    up with it myself before I ever heard of BPE.

Dear Stefan,

You did not specify what programming language you used for your project,
but I've used KyTea in C++ with great success, so I'm re-adding comp.
lang.c++.

   https://www.phontron.com/kytea

   https://github.com/neubig/kytea

> 
>    Japanese words are usually not separated by spaces. So, my
>    program just observes which combinations of characters appear
>    most frequently in my collection of Japanese texts, but also
>    can deal with words that appear both separated from other words
>    and also as parts of other words. For example, below both "ああ"
>    and "あ" are listed, and the 2*32232 occurences of "あ" in "ああ"
>    are not counted again to get the 22929 occurences of "あ".
> 
>    These are "words" by the definition of my program - which might
>    not agree with other definitions.

For brute force methods, you can also use Jim Breen's dictionary files,
but I have not worked with them directly yet, so cannot say how well
that works in practice.

> 
>    So, now you know which "words" you should learn first because
>    they are most common - from the output of my program (start):
> 
>    It says, "Hai" ("yes") is the most common Japanese word! Readers
>    might be surprised by "ああ" - this appears often in the spoken
>    language I was interested in, but rarely in formal texts.

That's interesting.  I've added japan.lang.japanese, tnn.os.bsd386.
japanese, and uiuc.org.japanese to this discussion, in case someone
there wants to comment on frequent words that don't appear in formal
texts.

> 
>    And we see that the few kanji I know ("何", "私", and "今") are
>    indeed very common! Again the 15591 hits of "何" in isolation
>    are counted only when its not part of the "何か", "何で", and
>    "何だ", which are listed and counted separately. And this also
>    applies to longer sequences correspondingly.
> 
[snip dictionary output].

I also know a few kanji.  Some we can blame on misspent youth, but that
is neither here nor there.  For instance, knowing how "mochiron" = /of
course/ is written in kanji "勿論" is of no use when taking the N5 exam.

A lot of Japanese people don't know this combination of kanji, and will
have to look it up in a dictionary -- or so I've been told.

I don't have a Japanese input method running, and had to copy this from
Jim Breen's website, so I'll refrain from pretending to know much more
of Japanese; mine has gotten quite rusty.

I am working on starting a local /Japanese study group/, but it's been
hard to get everyone together with a regular schedule.  So let's see how
that adventure goes.

I've added comp.edu.languages.natural to this discussion as well.

What educational material do you use when studying Japanese?  For my
next adventure, I've selected

   https://shop.thegreatcourses.com/learning-japanese-a-gateway-into-culture

and I also have a few books on the subject.


Best wishes, and happy Japanese language studies!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#11886 — Resources to learn Japanese (was: Resources to learn common lisp?)

"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>What educational material do you use when studying Japanese?

  By the way, a Newsgroups header with many newsgroups is sometimes used
  by spammers, and some newsreader does not even show posts crossposted
  to more than two or three newsgroups. "japan.lang.japanese" might
  be intended for messages in Japanese, and a Subject about Common Lisp
  might look even more like spam in Japanese newsgroups. So I just set
  a Followup-To to a group of which I know that it has had at least
  some traffic in recent years (one can ignore the "sci").

  A snippet from a search engine:

|Netiquette - The Document Foundation Wiki
|18 May 2024 ... Avoid Crossposting. It is almost never
|appropriate to send the same ... Or, if you must, make sure
|you set the Followup-To ...

  Well, my own level is far below N5 (absolute beginner); I only know
  few tiny fragments of Japanese. So all study material I know is
  actually far above my own level. But without further ado, here's the
  best site I know; it's much too advanced for me, but it's very good.

  If nothing has changed, it should contain loads of free
  downloadable mp3s and a PDF with transcripts. The site should
  be findable by "Japanese Audio Flashcard Lessons", and the
  domain name contains "japaneseaudiolessons".

  The audio starts with:

|This is Japanese audio flashcards, lesson one.
|"Please show the passport!" - use the "te" or "de" form of the verb!
|パスポートを見せてください。
|Pasupooto wo misete kudasai.

  When starting an mp3, you get an English prompt and then should
  responds with the Japanese translation which you then can also
  hear. I like this, because I can listen to it when I am doing
  something else but still have the capacity to listen. Also,
  I prefer to learn a language by listening instead of reading.

Newsgroups: comp.lang.misc,comp.lang.c++,comp.edu.languages.natural,japan.lang.japanese,tnn.os.bsd386.japanese,uiuc.org.japanese

Followup-To: sci.lang.japan

[toc] | [prev] | [next] | [standalone]

#11877

On Fri, 18 Sep 2026 11:05:46 +0800
"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> gabbled:
>Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>ular expression to match ' only if it's inside a word?  Do we want to
>account for Unicode single curly quotes too?

Instead of ever niche academic circle jerking wrt C++ expansion, it would be
nice if some more basic stuff was added first that other languages have 
supported since their inception. Eg, how about a switch() construct that 
operated on more than just POD types?

std::string mystr = "hello";
:
:
switch(mystr)
{
case "hello": ...
case "world": ...
:
}

etc.

So long as the object had operator==() defined I see no problem with overloading
switch in this way.

The amount of times I've had to write endless if-else's instead of this I've
lost count of.

[toc] | [prev] | [next] | [standalone]

#11879

boltar@caprica.universe writes:   Eg, how about a switch() construct that 
>operated on more than just POD types?

  Expected in C++29:

inspect (mystr) {
    "hello" => { /* ... */ },
    "world" => { /* ... */ },
    _       => { /* default */ }
};

Newsgroups: comp.lang.misc,comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#11881

On 18 Sep 2026 15:25:17 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>boltar@caprica.universe writes:   Eg, how about a switch() construct that 
>>operated on more than just POD types?
>
>  Expected in C++29:
>
>inspect (mystr) {
>    "hello" => { /* ... */ },
>    "world" => { /* ... */ },
>    _       => { /* default */ }
>};

Wtf?? Why an entirely new construct, just overload switch! Also I can 
guarantee than there's a ton of current code that will already be using the
word "inspect" in some way.

[toc] | [prev] | [next] | [standalone]

#11882

boltar@caprica.universe wrote or quoted:
>      Why an entirely new construct, just overload switch!

  Switch already has fall-through semantic which is not desired
  for the new inspect statement. Also parsing both the old and
  the new "case" syntax can become difficult.

>Also I can guarantee than there's a ton of current code that
>will already be using the word "inspect" in some way.

  If the compiler sees "inspect (variable) { ... }", it parses
  it as a pattern-matching block.

  If it sees "int inspect = 5;" or "my_object.inspect()", it treats
  it as a completely valid standard identifier.

Newsgroups: comp.lang.misc,comp.lang.c++
Followup-to: comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#11887

On 18 Sep 2026 16:05:52 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>boltar@caprica.universe wrote or quoted:
>>      Why an entirely new construct, just overload switch!
>
>  Switch already has fall-through semantic which is not desired
>  for the new inspect statement. Also parsing both the old and

Says who?

>  the new "case" syntax can become difficult.

Rubbish. Other languages manage.

>>Also I can guarantee than there's a ton of current code that
>>will already be using the word "inspect" in some way.
>
>  If the compiler sees "inspect (variable) { ... }", it parses
>  it as a pattern-matching block.
>
>  If it sees "int inspect = 5;" or "my_object.inspect()", it treats
>  it as a completely valid standard identifier.

So we treat "inspect" differently to every other keyword in that it can be
used as a variable/function/whatever name too? Well that won't be confusing
at all!

[toc] | [prev] | [next] | [standalone]

#11888

On 9/19/2026 4:29 PM, boltar@caprica.universe wrote:
> On 18 Sep 2026 16:05:52 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>> boltar@caprica.universe wrote or quoted:
>>>       Why an entirely new construct, just overload switch!
>>
>>   Switch already has fall-through semantic which is not desired
>>   for the new inspect statement. Also parsing both the old and
> 
> Says who?
> 
>>   the new "case" syntax can become difficult.
> 
> Rubbish. Other languages manage.
> 
>>> Also I can guarantee than there's a ton of current code that
>>> will already be using the word "inspect" in some way.
>>
>>   If the compiler sees "inspect (variable) { ... }", it parses
>>   it as a pattern-matching block.
>>
>>   If it sees "int inspect = 5;" or "my_object.inspect()", it treats
>>   it as a completely valid standard identifier.
> 
> So we treat "inspect" differently to every other keyword in that it can be
> used as a variable/function/whatever name too? Well that won't be confusing
> at all!

I don't think that's a problem.  C++ has already maximized the confu-
sion.  What we now have is a saturation of confuddlement, so we can just
change the syntax as we please.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#11884

On 18/09/2026 17:49, boltar@caprica.universe wrote:
> On 18 Sep 2026 15:25:17 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>> boltar@caprica.universe writes:   Eg, how about a switch() construct that
>>> operated on more than just POD types?
>>
>>   Expected in C++29:
>>
>> inspect (mystr) {
>>     "hello" => { /* ... */ },
>>     "world" => { /* ... */ },
>>     _       => { /* default */ }
>> };
> 
> Wtf?? Why an entirely new construct, just overload switch! Also I can
> guarantee than there's a ton of current code that will already be using the
> word "inspect" in some way.
> 

"inspect" is /not/ expected in C++29 - Stefan is a bit out of date.  It 
was one of several alternative proposals for a new pattern-matching 
feature.  The current candidate is "match", with a syntax like :

	x match {
		0 => std::printf("zero");
		1 => std::printf("one");
		_ => std::printf("something else");
	}

This works like a normal "switch", but there is no fall-through (so no 
"break" statements), and it is not weirdly unstructured.

	s match {
		"zero" => std::printf("zero");
		"one" => std::printf("one");
		_ => std::printf("something else");
	}

It will work with any literal types.  It can also be used to match 
variant types, polymorphic types, etc.

And there are few situations where an existing identifier "match" could 
be in conflict with the new keyword.  (You could cause trouble with a 
macro called "match", but that seems unlikely in real code.)

[toc] | [prev] | [next] | [standalone]

#11885

On 9/19/2026 12:18 AM, David Brown wrote:
> On 18/09/2026 17:49, boltar@caprica.universe wrote:
>> On 18 Sep 2026 15:25:17 GMT
>> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>>> boltar@caprica.universe writes:   Eg, how about a switch() construct 
>>> that
>>>> operated on more than just POD types?
>>>
>>>   Expected in C++29:
>>>
>>> inspect (mystr) {
>>>     "hello" => { /* ... */ },
>>>     "world" => { /* ... */ },
>>>     _       => { /* default */ }
>>> };
>>
>> Wtf?? Why an entirely new construct, just overload switch! Also I can
>> guarantee than there's a ton of current code that will already be 
>> using the
>> word "inspect" in some way.
>>
> 
> "inspect" is /not/ expected in C++29 - Stefan is a bit out of date.  It 
> was one of several alternative proposals for a new pattern-matching 
> feature.  The current candidate is "match", with a syntax like :
> 
>      x match {
>          0 => std::printf("zero");
>          1 => std::printf("one");
>          _ => std::printf("something else");
>      }
> 
> This works like a normal "switch", but there is no fall-through (so no 
> "break" statements), and it is not weirdly unstructured.
> 
>      s match {
>          "zero" => std::printf("zero");
>          "one" => std::printf("one");
>          _ => std::printf("something else");
>      }
> 
> It will work with any literal types.  It can also be used to match 
> variant types, polymorphic types, etc.
> 
> And there are few situations where an existing identifier "match" could 
> be in conflict with the new keyword.  (You could cause trouble with a 
> macro called "match", but that seems unlikely in real code.)

This is more akin to the original -- I believe -- the ML of Edinburgh.
Which is also what people have come to expect from Rust.  Though full
disclosure, I haven't reached the pattern matching in my studies of Rust
yet, and my ML is rusty.

So I think this is going in the right direction, by giving people what
they expect from other programming languages.  The keyword conflict is
unfortunate, though.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#11889 — Why no string switch? (was: Resources to learn common lisp?)

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>inspect (mystr) {
>    "hello" => { /* ... */ },

  Why there is no string "switch" statement in C++

  C++ is a systems programming language with zero-cost abstraction.

  The core language consists of predictable, low-level primitives
  (like "if", "while", "switch", or "+") that map to basic machine
  instructions and require minimal runtime overhead.
 
  If a native C++ inspect statement allowed matching a string variable
  against string cases, a single "primitive-looking" statement would 
  actually execute an O(N) string-comparison loop at runtime. Depending
  on how the compiler tries to optimize it, it might generate a sequen-
  tial chain of string comparisons, a trie structure, or a hashing rou-
  tine.

  Introducing a feature into the core language grammar that can intro-
  spect, match, and switch on complex string types blurs the historical
  boundary between lightweight primitive instructions in the core lan-
  guage and complex library types, making it more difficult for program-
  mers to "see" the run-time costs of core language features.

Newsgroups: comp.lang.misc,comp.lang.c++
Followup-To: comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#11890 — Re: Why no string switch? (was: Resources to learn common lisp?)

On 19 Sep 2026 12:46:17 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>inspect (mystr) {
>>    "hello" => { /* ... */ },
>
>  Why there is no string "switch" statement in C++
>
>  C++ is a systems programming language with zero-cost abstraction.
>
>  The core language consists of predictable, low-level primitives
>  (like "if", "while", "switch", or "+") that map to basic machine
>  instructions and require minimal runtime overhead.
> 
>  If a native C++ inspect statement allowed matching a string variable
>  against string cases, a single "primitive-looking" statement would 
>  actually execute an O(N) string-comparison loop at runtime. Depending
>  on how the compiler tries to optimize it, it might generate a sequen-
>  tial chain of string comparisons, a trie structure, or a hashing rou-
>  tine.

And? for() used to just be a simple comparison check loop then ranged for
loops were introduced. Functions had to be defined inline then lambdas were
introduced. Whats your point? There's no reason switch() can't be internally 
overloaded so a POD switch continues to be compiled down to a simple jump table 
whilst more complicated comparisons generate an if-else tree.

>  Introducing a feature into the core language grammar that can intro-
>  spect, match, and switch on complex string types blurs the historical
>  boundary between lightweight primitive instructions in the core lan-
>  guage and complex library types, making it more difficult for program-
>  mers to "see" the run-time costs of core language features.

That might be the case if the last 15 years of C++ development didn't prove
otherwise.

[toc] | [prev] | [next] | [standalone]

#11880

On 9/18/2026 11:11 PM, boltar@caprica.universe wrote:
> On Fri, 18 Sep 2026 11:05:46 +0800
> "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> gabbled:
>> Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>> ular expression to match ' only if it's inside a word?  Do we want to
>> account for Unicode single curly quotes too?
> 
> Instead of ever niche academic circle jerking wrt C++ expansion, it 
> would be
> nice if some more basic stuff was added first that other languages have 
> supported since their inception. Eg, how about a switch() construct that 
> operated on more than just POD types?
> 
> std::string mystr = "hello";
> :
> :
> switch(mystr)
> {
> case "hello": ...
> case "world": ...
> :
> }
> 
> etc.
> 
> So long as the object had operator==() defined I see no problem with 
> overloading
> switch in this way.
> 
> The amount of times I've had to write endless if-else's instead of this 
> I've
> lost count of.

I honestly agree with you.  Stroustrup has added almost everything to
C++, so this lack of a generic switch () is astounding.

Now, by merely adding PCRE2 to the compiler, we can even extend this
syntax to A.W.K. like matching, for something akin to

   switch( str ) {
     case /re1/: ...
     case /re2/: ...
   }

but that's better left as an exercise /after/ we get more generic switch
() into standard C++.


After all, everyone should be familiar with this kind of pattern match-
ing syntax in Dtrace.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.misc

csiph-web