TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The joy of concurrent logic programming

99 pointsby aarroyocover 3 years ago

8 comments

triskaover 3 years ago
Definitely an interesting read! I have a few comments about the following paragraph specifically, because the potential of convenient string processing is so essential to logic programming:<p><i>&quot;As in Prolog, strings are lists of character codes which makes them automatically suitable for stream processing. Apart from avoiding the tedious duplication of list and string manipulation operations, this allows for efficient, asynchronous handling of streams of characters, so the extra space needed for lists is partially balanced by manipulating them in a lazy manner, one piece at a time, by communicating processes.&quot;</i><p>In Prolog, the meaning of double-quoted strings depends on the value of the Prolog flag double_quotes. Only if it is set to the value <i>codes</i> are double-quoted strings interpreted as lists of codes. However, a much better setting is the value <i>chars</i>, and then double-quoted strings are interpreted as lists of 1-char <i>atoms</i>. For example, with this setting, we have:<p><pre><code> ?- &quot;abc&quot; = [a|Ls]. Ls = &quot;bc&quot;. </code></pre> This is the default value in all of the three newest Prolog systems: Scryer Prolog, Tau Prolog and Trealla Prolog. It was also the original interpretation of strings in the very first Prolog systems, Prolog 0 and Marseille Prolog, which were designed for natural language processing. Lists of characters ensure that strings are very readable, also when emitted in their canonical representation. For example, Scryer Prolog yields:<p><pre><code> ?- write_canonical(&quot;abc&quot;). &#x27;.&#x27;(a,&#x27;.&#x27;(b,&#x27;.&#x27;(c,[]))) true. </code></pre> The mentioned advantage of &quot;avoiding the tedious duplication of list and string manipulation operations&quot; in this way can hardly be overstated: It is massive, because everything one knows about lists carries over directly to strings, including common predicates such as append&#x2F;3, length&#x2F;2 and reverse&#x2F;2 which even beginning Prolog programmers universally know, and the ability to <i>generalize</i> arbitrary elements by using logic variables at desired positions, obtaining partially instantiated terms such as &quot;all strings of length 3&quot; which can be specified symbolically as [_,_,_]. In addition, lists are especially conveniently reasoned about with Prolog&#x27;s built-in grammar mechanism, definite clause grammars (DCGs), tailor-made for generating and parsing sequences and therefore also strings. And further, &quot;the extra space needed for lists&quot; can be avoided with a compact internal representation of lists of characters, i.e., encoding them as sequences of raw bytes, using UTF-8 encoding. This efficient representation is currently already implemented in Scryer Prolog and Trealla Prolog.
OliverMover 3 years ago
The author doesn&#x27;t mention it but Concepts, Techniques and Models of Computer Programming by Haridi &amp; Van Roy teaches concurrent logic programming (as part of a tour through a wide variety of programming models, including logic programming, stateful concurrency, and constraint programming). It&#x27;s a great introduction to the paradigm. The full text is available online: <a href="https:&#x2F;&#x2F;www.info.ucl.ac.be&#x2F;~pvr&#x2F;VanRoyHaridi2003-book.pdf" rel="nofollow">https:&#x2F;&#x2F;www.info.ucl.ac.be&#x2F;~pvr&#x2F;VanRoyHaridi2003-book.pdf</a>
评论 #29143522 未加载
PaulHouleover 3 years ago
My concern is how you batch things.<p>If you pass single operations between threads you will run slower, not faster because of the synchronization overhead.<p>Whenever I parallelize something I build batching in from the beginning. Most other people seem to think it is an optimization you can do later but the way I see if if your goal is to get any speed up at all batching is essential.
评论 #29142277 未加载
评论 #29143145 未加载
评论 #29140125 未加载
infogulchover 3 years ago
I like the exploration of a different execution model over a prolog-like syntax. Even without concurrency as a headline feature, this seems like a good basis for a language&#x27;s computational model. I always felt like prolog default of executing terms in written-order sacrifices too much power for implementation convenience, which rules out a large well of potential optimizations and generalities.<p>&gt; the order in which these unifications take place is immaterial, any order is fine ... if a logic variable is unbound, then matching a pattern containing such a variable suspends and does not continue until the variable has been bound.<p>&gt; There is no need to artificially orchestrate how the processes execute in parallel, this is done implicitly like the cells of a spreadsheet - once a required result is available, it may trigger further variables to be bound and processes to be resumed, and so on, until the network of processes settles.
marcleover 3 years ago
This is a very interesting article.<p>The author notes: &quot;There is a compiler for KL1 to C available [2], which seems to work, but suffers from bit rot.&quot; Note that Ueda and colleagues have been updating this software (KLIC): see <a href="https:&#x2F;&#x2F;www.ueda.info.waseda.ac.jp&#x2F;software.html" rel="nofollow">https:&#x2F;&#x2F;www.ueda.info.waseda.ac.jp&#x2F;software.html</a> for details. Ueda&#x27;s work on LMNtal is also very interesting.
Twisolover 3 years ago
Concurrent constraint programming is especially interesting to me -- Saraswat&#x27;s ideas about a general constraint store (versus the Herbrand domain Prolog is usually instantiated over) are genuinely fascinating to me. I see the relatively recent work on LVars as an example of where that flexibility really pays off.
seedless-sensatover 3 years ago
Unfortunately the line breaks make this unreadable on a phone
Syzygiesover 3 years ago
&quot;Especially today, where CPU designers have run out of ideas&quot;<p>I wonder how many readers made it past the formatting, only to stop reading here?
评论 #29142090 未加载
评论 #29141087 未加载
评论 #29141669 未加载
评论 #29140939 未加载
评论 #29141701 未加载