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

Groups > comp.lang.prolog > #13960 > unrolled thread

Not being a Haskell programmer is trendy!

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

Contents

  Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-02-02 20:46 +0100
    Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-02-02 21:00 +0100
      Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-02 12:50 -0800
        Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-07 03:25 -0800
      Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-11 14:34 -0800
        Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-11 14:39 -0800
          Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-14 06:45 -0800
            Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-14 06:53 -0800
    Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-14 13:29 -0800
      Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-14 13:33 -0800
    Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-02-21 01:27 +0100
      Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-02-21 01:28 +0100
        Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-02-21 01:30 +0100
          Re: Not being a Haskell programmer is trendy! Mild Shock <bursejan@gmail.com> - 2024-02-21 03:43 -0800
    Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 17:45 +0100
      Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 17:47 +0100
        Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 17:57 +0100
          Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 18:06 +0100
            Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 18:08 +0100
              Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 19:45 +0100
                Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-01 21:33 +0100
    Re: Not being a Haskell programmer is trendy! Mild Shock <janburse@fastmail.fm> - 2024-03-06 01:56 +0100

Page 1 of 2  [1] 2  Next page →

#13960 — Not being a Haskell programmer is trendy!

Just watched 2 videos from Scala and the
year 2023 and nearly chocked on my yoghurt,

especially when I saw the first presenter got a
headeache from early returns. LoL

Async/Await for the Monadic Programmer
https://www.youtube.com/watch?v=OH5cxLNTTPo

DIRECT STYLE SCALA Scalar Conference 2023
https://www.youtube.com/watch?v=0Fm0y4K4YO8

Whats the bottom line: All because they discovered they
could do async/await as well?

[toc] | [next] | [standalone]

#13961

BTW: The Go programming language which has direct
style runs the primes example in 0.6 seconds.
The primes example is here:

The Go Playground
https://go.dev/play/

Just choose the Concurrent Prime Sieve example.
Twice as slow as the 0.3 seconds of Haskell but
nevertheless faster than Prolog.

For those interested was comparing to:

Prolog Hand Rolled Lazy Lists via call/n:
=============================================

iter(F,A,A,iter(F,B)) :- call(F,A,B).

take(0, _, []) :- !.
take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L).

modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E).

modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E).
modfilt2(D, M, X, X, modfilt(D,M)).

primes(C, X, primes(modfilt(D,X))) :- call(C, X, D).

/* on @emiruz machine */
?- time(take(5000,primes(iter(succ,2)),_)). 

% 38,009,267 inferences, 2.005 CPU in 2.005
seconds (100% CPU, 18954407 Lips) 

true.

Haskell David Turner's sieve (SASL Language Manual, 1983)
=============================================

sieve :: [Integer] -> [Integer] 

sieve [] = [] 

sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0]

/* on @emiruz machine */
time ./primes
% real	0m0.312s
% user	0m0.294s
% sys	0m0.005s

https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division

Disclaimer: Didn't run the Go version by myself
yet. Have first to install Go etc.. Somebody
else run it and reported 0.6 seconds.

Mild Shock schrieb:
> Just watched 2 videos from Scala and the
> year 2023 and nearly chocked on my yoghurt,
> 
> especially when I saw the first presenter got a
> headeache from early returns. LoL
> 
> Async/Await for the Monadic Programmer
> https://www.youtube.com/watch?v=OH5cxLNTTPo
> 
> DIRECT STYLE SCALA Scalar Conference 2023
> https://www.youtube.com/watch?v=0Fm0y4K4YO8
> 
> Whats the bottom line: All because they discovered they
> could do async/await as well?

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

#13962

To be fair the problem itself is two loops, like here:

Primes via two loops
https://go.dev/play/p/3XNt-e3Ozw8?v=gotip

Which can do golang in 0.04 seconds. Is this translatable
to Prolog? Maybe via nb_setarg or via Schimpf loops?

Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1:
> BTW: The Go programming language which has direct 
> style runs the primes example in 0.6 seconds. 
> The primes example is here: 
> 
> The Go Playground 
> https://go.dev/play/ 
> 
> Just choose the Concurrent Prime Sieve example. 
> Twice as slow as the 0.3 seconds of Haskell but 
> nevertheless faster than Prolog. 
> 
> For those interested was comparing to: 
> 
> Prolog Hand Rolled Lazy Lists via call/n: 
> ============================================= 
> 
> iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> 
> take(0, _, []) :- !. 
> take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> 
> modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> 
> modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> modfilt2(D, M, X, X, modfilt(D,M)). 
> 
> primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> 
> /* on @emiruz machine */ 
> ?- time(take(5000,primes(iter(succ,2)),_)). 
> 
> % 38,009,267 inferences, 2.005 CPU in 2.005 
> seconds (100% CPU, 18954407 Lips) 
> 
> true. 
> 
> Haskell David Turner's sieve (SASL Language Manual, 1983) 
> ============================================= 
> 
> sieve :: [Integer] -> [Integer] 
> 
> sieve [] = [] 
> 
> sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> 
> /* on @emiruz machine */ 
> time ./primes 
> % real 0m0.312s 
> % user 0m0.294s 
> % sys 0m0.005s 
> 
> https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> 
> Disclaimer: Didn't run the Go version by myself 
> yet. Have first to install Go etc.. Somebody 
> else run it and reported 0.6 seconds. 
> 
> Mild Shock schrieb:
> > Just watched 2 videos from Scala and the 
> > year 2023 and nearly chocked on my yoghurt, 
> > 
> > especially when I saw the first presenter got a 
> > headeache from early returns. LoL 
> > 
> > Async/Await for the Monadic Programmer 
> > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > 
> > DIRECT STYLE SCALA Scalar Conference 2023 
> > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > 
> > Whats the bottom line: All because they discovered they 
> > could do async/await as well?

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

#13963

Now there is a funny article on the net:

The carcinization of Go programs
https://news.ycombinator.com/item?id=33713717

"Carcinisation (American English: carcinization) is a form of 
convergent evolution in which non-crab crustaceans 
evolve a crab-like body plan."
https://en.wikipedia.org/wiki/Carcinisation

I guess it is meant:

the crab = rust
the non-crab = golang

But I have some doubts. It seems there are indeed
programmers that don't care about a concise and elegant 
language. Yesterday my good night lecture was this blog post:

    Request coalescing in async Rust
    https://fasterthanli.me/articles/request-coalescing-in-async-rust#panic-at-the-in-flight-request

I don't know what this is. A kind of Lambda Hell?
Or some other sort of Hell? A generics parameterized
types Hell as well? A storage concurrency annotation Hell?

Thank god Prolog has no type declarations.

Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:50:09 UTC+1:
> To be fair the problem itself is two loops, like here: 
> 
> Primes via two loops 
> https://go.dev/play/p/3XNt-e3Ozw8?v=gotip 
> 
> Which can do golang in 0.04 seconds. Is this translatable 
> to Prolog? Maybe via nb_setarg or via Schimpf loops?
> Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1: 
> > BTW: The Go programming language which has direct 
> > style runs the primes example in 0.6 seconds. 
> > The primes example is here: 
> > 
> > The Go Playground 
> > https://go.dev/play/ 
> > 
> > Just choose the Concurrent Prime Sieve example. 
> > Twice as slow as the 0.3 seconds of Haskell but 
> > nevertheless faster than Prolog. 
> > 
> > For those interested was comparing to: 
> > 
> > Prolog Hand Rolled Lazy Lists via call/n: 
> > ============================================= 
> > 
> > iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> > 
> > take(0, _, []) :- !. 
> > take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> > 
> > modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> > 
> > modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> > modfilt2(D, M, X, X, modfilt(D,M)). 
> > 
> > primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> > 
> > /* on @emiruz machine */ 
> > ?- time(take(5000,primes(iter(succ,2)),_)). 
> > 
> > % 38,009,267 inferences, 2.005 CPU in 2.005 
> > seconds (100% CPU, 18954407 Lips) 
> > 
> > true. 
> > 
> > Haskell David Turner's sieve (SASL Language Manual, 1983) 
> > ============================================= 
> > 
> > sieve :: [Integer] -> [Integer] 
> > 
> > sieve [] = [] 
> > 
> > sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> > 
> > /* on @emiruz machine */ 
> > time ./primes 
> > % real 0m0.312s 
> > % user 0m0.294s 
> > % sys 0m0.005s 
> > 
> > https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> > 
> > Disclaimer: Didn't run the Go version by myself 
> > yet. Have first to install Go etc.. Somebody 
> > else run it and reported 0.6 seconds. 
> > 
> > Mild Shock schrieb: 
> > > Just watched 2 videos from Scala and the 
> > > year 2023 and nearly chocked on my yoghurt, 
> > > 
> > > especially when I saw the first presenter got a 
> > > headeache from early returns. LoL 
> > > 
> > > Async/Await for the Monadic Programmer 
> > > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > > 
> > > DIRECT STYLE SCALA Scalar Conference 2023 
> > > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > > 
> > > Whats the bottom line: All because they discovered they 
> > > could do async/await as well?

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

#13965

I tried Erlang. But it cannot deal with the problem, because actors
in Erlang have unbounded inboxes, and there is no backpressure from
the consumer back to the producers. So the iterator producer will spin 

like wild and clog the processor. I can run N=100, but N=5000 explodes:
```
-module(sieve).

-export([main/1]).

above(PID, AT) ->
   PID ! AT,
   AT2 = AT+1,
   above(PID, AT2).

filter(PID, MOD) ->
   receive
      AT -> if AT rem MOD =/= 0 ->
               PID ! AT;
              true -> true
            end
   end,
   filter(PID, MOD).

sift(PID) ->
    receive
        AT -> PID ! AT,
          PID2 = spawn(fun() -> sift(PID) end),
          filter(PID2, AT)
    end.

take(COUNT) ->
  if COUNT =/= 0 ->
    receive
       AT -> if COUNT =:= 1 -> io:format("~w~n", [AT]);
               true -> true end
    end,
    COUNT2 = COUNT-1,
    take(COUNT2);
    true -> true
  end.

main(_) ->
  PID = self(),
  PID2 = spawn(fun() -> sift(PID) end),
  spawn(fun() -> above(PID2, 2) end),
  take(100).
%  explodes:
%  take(5000).
```

Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1:
> BTW: The Go programming language which has direct 
> style runs the primes example in 0.6 seconds. 
> The primes example is here: 
> 
> The Go Playground 
> https://go.dev/play/ 
> 
> Just choose the Concurrent Prime Sieve example. 
> Twice as slow as the 0.3 seconds of Haskell but 
> nevertheless faster than Prolog. 
> 
> For those interested was comparing to: 
> 
> Prolog Hand Rolled Lazy Lists via call/n: 
> ============================================= 
> 
> iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> 
> take(0, _, []) :- !. 
> take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> 
> modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> 
> modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> modfilt2(D, M, X, X, modfilt(D,M)). 
> 
> primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> 
> /* on @emiruz machine */ 
> ?- time(take(5000,primes(iter(succ,2)),_)). 
> 
> % 38,009,267 inferences, 2.005 CPU in 2.005 
> seconds (100% CPU, 18954407 Lips) 
> 
> true. 
> 
> Haskell David Turner's sieve (SASL Language Manual, 1983) 
> ============================================= 
> 
> sieve :: [Integer] -> [Integer] 
> 
> sieve [] = [] 
> 
> sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> 
> /* on @emiruz machine */ 
> time ./primes 
> % real 0m0.312s 
> % user 0m0.294s 
> % sys 0m0.005s 
> 
> https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> 
> Disclaimer: Didn't run the Go version by myself 
> yet. Have first to install Go etc.. Somebody 
> else run it and reported 0.6 seconds. 
> 
> Mild Shock schrieb:
> > Just watched 2 videos from Scala and the 
> > year 2023 and nearly chocked on my yoghurt, 
> > 
> > especially when I saw the first presenter got a 
> > headeache from early returns. LoL 
> > 
> > Async/Await for the Monadic Programmer 
> > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > 
> > DIRECT STYLE SCALA Scalar Conference 2023 
> > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > 
> > Whats the bottom line: All because they discovered they 
> > could do async/await as well?

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

#13966

An interesting experiment could be to distribute such actors
via SWI-Prolog pengines over a couple of nodes in a network. Can 
it handle backpressure? 

How would it compare to these suggestions here:

Golang: out-of-box backpressure handling with gRPC, proven by a Grafana dashboard
gRPC and the underlying HTTP/2 protocol handle flow control. This means the server can only send data as fast as the client can consume, preventing overwhelming the client.
https://www.linkedin.com/pulse/golang-out-of-box-backpressure-handling-grpc-proven-grafana-melo

What would be the dashboard?

Mild Shock schrieb am Sonntag, 11. Februar 2024 um 23:34:11 UTC+1:
> I tried Erlang. But it cannot deal with the problem, because actors 
> in Erlang have unbounded inboxes, and there is no backpressure from 
> the consumer back to the producers. So the iterator producer will spin 
> 
> like wild and clog the processor. I can run N=100, but N=5000 explodes: 
> ``` 
> -module(sieve). 
> 
> -export([main/1]). 
> 
> above(PID, AT) -> 
> PID ! AT, 
> AT2 = AT+1, 
> above(PID, AT2). 
> 
> filter(PID, MOD) -> 
> receive 
> AT -> if AT rem MOD =/= 0 -> 
> PID ! AT; 
> true -> true 
> end 
> end, 
> filter(PID, MOD). 
> 
> sift(PID) -> 
> receive 
> AT -> PID ! AT, 
> PID2 = spawn(fun() -> sift(PID) end), 
> filter(PID2, AT) 
> end. 
> 
> take(COUNT) -> 
> if COUNT =/= 0 -> 
> receive 
> AT -> if COUNT =:= 1 -> io:format("~w~n", [AT]); 
> true -> true end 
> end, 
> COUNT2 = COUNT-1, 
> take(COUNT2); 
> true -> true 
> end. 
> 
> main(_) -> 
> PID = self(), 
> PID2 = spawn(fun() -> sift(PID) end), 
> spawn(fun() -> above(PID2, 2) end), 
> take(100). 
> % explodes: 
> % take(5000). 
> ```
> Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1: 
> > BTW: The Go programming language which has direct 
> > style runs the primes example in 0.6 seconds. 
> > The primes example is here: 
> > 
> > The Go Playground 
> > https://go.dev/play/ 
> > 
> > Just choose the Concurrent Prime Sieve example. 
> > Twice as slow as the 0.3 seconds of Haskell but 
> > nevertheless faster than Prolog. 
> > 
> > For those interested was comparing to: 
> > 
> > Prolog Hand Rolled Lazy Lists via call/n: 
> > ============================================= 
> > 
> > iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> > 
> > take(0, _, []) :- !. 
> > take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> > 
> > modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> > 
> > modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> > modfilt2(D, M, X, X, modfilt(D,M)). 
> > 
> > primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> > 
> > /* on @emiruz machine */ 
> > ?- time(take(5000,primes(iter(succ,2)),_)). 
> > 
> > % 38,009,267 inferences, 2.005 CPU in 2.005 
> > seconds (100% CPU, 18954407 Lips) 
> > 
> > true. 
> > 
> > Haskell David Turner's sieve (SASL Language Manual, 1983) 
> > ============================================= 
> > 
> > sieve :: [Integer] -> [Integer] 
> > 
> > sieve [] = [] 
> > 
> > sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> > 
> > /* on @emiruz machine */ 
> > time ./primes 
> > % real 0m0.312s 
> > % user 0m0.294s 
> > % sys 0m0.005s 
> > 
> > https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> > 
> > Disclaimer: Didn't run the Go version by myself 
> > yet. Have first to install Go etc.. Somebody 
> > else run it and reported 0.6 seconds. 
> > 
> > Mild Shock schrieb: 
> > > Just watched 2 videos from Scala and the 
> > > year 2023 and nearly chocked on my yoghurt, 
> > > 
> > > especially when I saw the first presenter got a 
> > > headeache from early returns. LoL 
> > > 
> > > Async/Await for the Monadic Programmer 
> > > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > > 
> > > DIRECT STYLE SCALA Scalar Conference 2023 
> > > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > > 
> > > Whats the bottom line: All because they discovered they 
> > > could do async/await as well?

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

#13971

What would be cool, if the actors could interact via websockets
with each other. Not sure. Or anything that could provide some 
backpressure feedback. A websocket could provide backpressure

in two ways, either by implicitly by blocking a single channel when 
sending  payload, if this is possible, or more explicitly by using the 
other channel,  for some control flow information.

BTW: I missed this one: Already 5 years old / 
just before Corona [RFC 8441]:

HTTP/2 WebSockets
HTTP/2 was standardized in 2015 without any mention
of WebSockets. For most of the time since then I assumed
that there would be no WebSockets over HTTP/2. That
changed in September last year with the publication of
RFC 8441, which will be supported in browsers in 2019
approximately 10 years after WebSockets were first introduced.
https://medium.com/@pgjones/http-2-websockets-81ae3aab36dd

Mild Shock schrieb am Sonntag, 11. Februar 2024 um 23:39:31 UTC+1:
> An interesting experiment could be to distribute such actors 
> via SWI-Prolog pengines over a couple of nodes in a network. Can 
> it handle backpressure? 
> 
> How would it compare to these suggestions here: 
> 
> Golang: out-of-box backpressure handling with gRPC, proven by a Grafana dashboard 
> gRPC and the underlying HTTP/2 protocol handle flow control. This means the server can only send data as fast as the client can consume, preventing overwhelming the client. 
> https://www.linkedin.com/pulse/golang-out-of-box-backpressure-handling-grpc-proven-grafana-melo 
> 
> What would be the dashboard?
> Mild Shock schrieb am Sonntag, 11. Februar 2024 um 23:34:11 UTC+1: 
> > I tried Erlang. But it cannot deal with the problem, because actors 
> > in Erlang have unbounded inboxes, and there is no backpressure from 
> > the consumer back to the producers. So the iterator producer will spin 
> > 
> > like wild and clog the processor. I can run N=100, but N=5000 explodes: 
> > ``` 
> > -module(sieve). 
> > 
> > -export([main/1]). 
> > 
> > above(PID, AT) -> 
> > PID ! AT, 
> > AT2 = AT+1, 
> > above(PID, AT2). 
> > 
> > filter(PID, MOD) -> 
> > receive 
> > AT -> if AT rem MOD =/= 0 -> 
> > PID ! AT; 
> > true -> true 
> > end 
> > end, 
> > filter(PID, MOD). 
> > 
> > sift(PID) -> 
> > receive 
> > AT -> PID ! AT, 
> > PID2 = spawn(fun() -> sift(PID) end), 
> > filter(PID2, AT) 
> > end. 
> > 
> > take(COUNT) -> 
> > if COUNT =/= 0 -> 
> > receive 
> > AT -> if COUNT =:= 1 -> io:format("~w~n", [AT]); 
> > true -> true end 
> > end, 
> > COUNT2 = COUNT-1, 
> > take(COUNT2); 
> > true -> true 
> > end. 
> > 
> > main(_) -> 
> > PID = self(), 
> > PID2 = spawn(fun() -> sift(PID) end), 
> > spawn(fun() -> above(PID2, 2) end), 
> > take(100). 
> > % explodes: 
> > % take(5000). 
> > ``` 
> > Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1: 
> > > BTW: The Go programming language which has direct 
> > > style runs the primes example in 0.6 seconds. 
> > > The primes example is here: 
> > > 
> > > The Go Playground 
> > > https://go.dev/play/ 
> > > 
> > > Just choose the Concurrent Prime Sieve example. 
> > > Twice as slow as the 0.3 seconds of Haskell but 
> > > nevertheless faster than Prolog. 
> > > 
> > > For those interested was comparing to: 
> > > 
> > > Prolog Hand Rolled Lazy Lists via call/n: 
> > > ============================================= 
> > > 
> > > iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> > > 
> > > take(0, _, []) :- !. 
> > > take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> > > 
> > > modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> > > 
> > > modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> > > modfilt2(D, M, X, X, modfilt(D,M)). 
> > > 
> > > primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> > > 
> > > /* on @emiruz machine */ 
> > > ?- time(take(5000,primes(iter(succ,2)),_)). 
> > > 
> > > % 38,009,267 inferences, 2.005 CPU in 2.005 
> > > seconds (100% CPU, 18954407 Lips) 
> > > 
> > > true. 
> > > 
> > > Haskell David Turner's sieve (SASL Language Manual, 1983) 
> > > ============================================= 
> > > 
> > > sieve :: [Integer] -> [Integer] 
> > > 
> > > sieve [] = [] 
> > > 
> > > sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> > > 
> > > /* on @emiruz machine */ 
> > > time ./primes 
> > > % real 0m0.312s 
> > > % user 0m0.294s 
> > > % sys 0m0.005s 
> > > 
> > > https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> > > 
> > > Disclaimer: Didn't run the Go version by myself 
> > > yet. Have first to install Go etc.. Somebody 
> > > else run it and reported 0.6 seconds. 
> > > 
> > > Mild Shock schrieb: 
> > > > Just watched 2 videos from Scala and the 
> > > > year 2023 and nearly chocked on my yoghurt, 
> > > > 
> > > > especially when I saw the first presenter got a 
> > > > headeache from early returns. LoL 
> > > > 
> > > > Async/Await for the Monadic Programmer 
> > > > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > > > 
> > > > DIRECT STYLE SCALA Scalar Conference 2023 
> > > > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > > > 
> > > > Whats the bottom line: All because they discovered they 
> > > > could do async/await as well?

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

#13972

Related to gRPC, but not yet provided by nginx:

https://trac.nginx.org/nginx/ticket/1992

Mild Shock schrieb am Mittwoch, 14. Februar 2024 um 15:45:56 UTC+1:
> What would be cool, if the actors could interact via websockets 
> with each other. Not sure. Or anything that could provide some 
> backpressure feedback. A websocket could provide backpressure 
> 
> in two ways, either by implicitly by blocking a single channel when 
> sending payload, if this is possible, or more explicitly by using the 
> other channel, for some control flow information. 
> 
> BTW: I missed this one: Already 5 years old / 
> just before Corona [RFC 8441]: 
> 
> HTTP/2 WebSockets 
> HTTP/2 was standardized in 2015 without any mention 
> of WebSockets. For most of the time since then I assumed 
> that there would be no WebSockets over HTTP/2. That 
> changed in September last year with the publication of 
> RFC 8441, which will be supported in browsers in 2019 
> approximately 10 years after WebSockets were first introduced. 
> https://medium.com/@pgjones/http-2-websockets-81ae3aab36dd
> Mild Shock schrieb am Sonntag, 11. Februar 2024 um 23:39:31 UTC+1: 
> > An interesting experiment could be to distribute such actors 
> > via SWI-Prolog pengines over a couple of nodes in a network. Can 
> > it handle backpressure? 
> > 
> > How would it compare to these suggestions here: 
> > 
> > Golang: out-of-box backpressure handling with gRPC, proven by a Grafana dashboard 
> > gRPC and the underlying HTTP/2 protocol handle flow control. This means the server can only send data as fast as the client can consume, preventing overwhelming the client. 
> > https://www.linkedin.com/pulse/golang-out-of-box-backpressure-handling-grpc-proven-grafana-melo 
> > 
> > What would be the dashboard? 
> > Mild Shock schrieb am Sonntag, 11. Februar 2024 um 23:34:11 UTC+1: 
> > > I tried Erlang. But it cannot deal with the problem, because actors 
> > > in Erlang have unbounded inboxes, and there is no backpressure from 
> > > the consumer back to the producers. So the iterator producer will spin 
> > > 
> > > like wild and clog the processor. I can run N=100, but N=5000 explodes: 
> > > ``` 
> > > -module(sieve). 
> > > 
> > > -export([main/1]). 
> > > 
> > > above(PID, AT) -> 
> > > PID ! AT, 
> > > AT2 = AT+1, 
> > > above(PID, AT2). 
> > > 
> > > filter(PID, MOD) -> 
> > > receive 
> > > AT -> if AT rem MOD =/= 0 -> 
> > > PID ! AT; 
> > > true -> true 
> > > end 
> > > end, 
> > > filter(PID, MOD). 
> > > 
> > > sift(PID) -> 
> > > receive 
> > > AT -> PID ! AT, 
> > > PID2 = spawn(fun() -> sift(PID) end), 
> > > filter(PID2, AT) 
> > > end. 
> > > 
> > > take(COUNT) -> 
> > > if COUNT =/= 0 -> 
> > > receive 
> > > AT -> if COUNT =:= 1 -> io:format("~w~n", [AT]); 
> > > true -> true end 
> > > end, 
> > > COUNT2 = COUNT-1, 
> > > take(COUNT2); 
> > > true -> true 
> > > end. 
> > > 
> > > main(_) -> 
> > > PID = self(), 
> > > PID2 = spawn(fun() -> sift(PID) end), 
> > > spawn(fun() -> above(PID2, 2) end), 
> > > take(100). 
> > > % explodes: 
> > > % take(5000). 
> > > ``` 
> > > Mild Shock schrieb am Freitag, 2. Februar 2024 um 21:00:44 UTC+1: 
> > > > BTW: The Go programming language which has direct 
> > > > style runs the primes example in 0.6 seconds. 
> > > > The primes example is here: 
> > > > 
> > > > The Go Playground 
> > > > https://go.dev/play/ 
> > > > 
> > > > Just choose the Concurrent Prime Sieve example. 
> > > > Twice as slow as the 0.3 seconds of Haskell but 
> > > > nevertheless faster than Prolog. 
> > > > 
> > > > For those interested was comparing to: 
> > > > 
> > > > Prolog Hand Rolled Lazy Lists via call/n: 
> > > > ============================================= 
> > > > 
> > > > iter(F,A,A,iter(F,B)) :- call(F,A,B). 
> > > > 
> > > > take(0, _, []) :- !. 
> > > > take(N, C, [X|L]) :- M is N-1, call(C, X, D), take(M, D, L). 
> > > > 
> > > > modfilt(C, M, X, E) :- call(C, Y, D), modfilt2(D, M, Y, X, E). 
> > > > 
> > > > modfilt2(D, M, Y, X, E) :- Y mod M =:= 0, !, modfilt(D, M, X, E). 
> > > > modfilt2(D, M, X, X, modfilt(D,M)). 
> > > > 
> > > > primes(C, X, primes(modfilt(D,X))) :- call(C, X, D). 
> > > > 
> > > > /* on @emiruz machine */ 
> > > > ?- time(take(5000,primes(iter(succ,2)),_)). 
> > > > 
> > > > % 38,009,267 inferences, 2.005 CPU in 2.005 
> > > > seconds (100% CPU, 18954407 Lips) 
> > > > 
> > > > true. 
> > > > 
> > > > Haskell David Turner's sieve (SASL Language Manual, 1983) 
> > > > ============================================= 
> > > > 
> > > > sieve :: [Integer] -> [Integer] 
> > > > 
> > > > sieve [] = [] 
> > > > 
> > > > sieve (p:xs) = p : sieve [x | x <- xs, rem x p > 0] 
> > > > 
> > > > /* on @emiruz machine */ 
> > > > time ./primes 
> > > > % real 0m0.312s 
> > > > % user 0m0.294s 
> > > > % sys 0m0.005s 
> > > > 
> > > > https://wiki.haskell.org/Prime_numbers#Turner.27s_sieve_-_Trial_division 
> > > > 
> > > > Disclaimer: Didn't run the Go version by myself 
> > > > yet. Have first to install Go etc.. Somebody 
> > > > else run it and reported 0.6 seconds. 
> > > > 
> > > > Mild Shock schrieb: 
> > > > > Just watched 2 videos from Scala and the 
> > > > > year 2023 and nearly chocked on my yoghurt, 
> > > > > 
> > > > > especially when I saw the first presenter got a 
> > > > > headeache from early returns. LoL 
> > > > > 
> > > > > Async/Await for the Monadic Programmer 
> > > > > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > > > > 
> > > > > DIRECT STYLE SCALA Scalar Conference 2023 
> > > > > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > > > > 
> > > > > Whats the bottom line: All because they discovered they 
> > > > > could do async/await as well?

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

#13973

Woa! Not the direct style:

Chapter 13: Asynchronous Tasks
https://github.com/benweidig/a-functional-approach-to-java/tree/main/part-2/13-asynchronous-tasks

From this book:

Functional Approach to Java - Ben Weidig
https://github.com/benweidig/a-functional-approach-to-java/tree/main/part-2/13-asynchronous-tasks

So is this book already maculature when it was publish?

What does your crystal ball say?

Mild Shock schrieb am Freitag, 2. Februar 2024 um 20:46:14 UTC+1:
> Just watched 2 videos from Scala and the 
> year 2023 and nearly chocked on my yoghurt, 
> 
> especially when I saw the first presenter got a 
> headeache from early returns. LoL 
> 
> Async/Await for the Monadic Programmer 
> https://www.youtube.com/watch?v=OH5cxLNTTPo 
> 
> DIRECT STYLE SCALA Scalar Conference 2023 
> https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> 
> Whats the bottom line: All because they discovered they 
> could do async/await as well?

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

#13974

Corr.: Wrong 2nd link. This surfaced May 19, 2023:

My book, “A Functional Approach to Java,” is finally here!
https://medium.com/@benweidig/my-book-a-functional-approach-to-java-is-finally-here-697a512f0b5b

Mild Shock schrieb am Mittwoch, 14. Februar 2024 um 22:29:49 UTC+1:
> Woa! Not the direct style: 
> 
> Chapter 13: Asynchronous Tasks 
> https://github.com/benweidig/a-functional-approach-to-java/tree/main/part-2/13-asynchronous-tasks 
> 
> From this book: 
> 
> Functional Approach to Java - Ben Weidig 
> https://github.com/benweidig/a-functional-approach-to-java/tree/main/part-2/13-asynchronous-tasks 
> 
> So is this book already maculature when it was publish? 
> 
> What does your crystal ball say?
> Mild Shock schrieb am Freitag, 2. Februar 2024 um 20:46:14 UTC+1: 
> > Just watched 2 videos from Scala and the 
> > year 2023 and nearly chocked on my yoghurt, 
> > 
> > especially when I saw the first presenter got a 
> > headeache from early returns. LoL 
> > 
> > Async/Await for the Monadic Programmer 
> > https://www.youtube.com/watch?v=OH5cxLNTTPo 
> > 
> > DIRECT STYLE SCALA Scalar Conference 2023 
> > https://www.youtube.com/watch?v=0Fm0y4K4YO8 
> > 
> > Whats the bottom line: All because they discovered they 
> > could do async/await as well?

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

#13981

My revecent Async/Await surrogates for JDK 21
provide coroutines with suspend/resume semantics.
They are not continuations. They aim is to provide
async/await and not only setTimeout().

As a result you don't need to write libraries
with a continuation parameters. This is very unlike
nonsense such as the JavaScript express web framework.

stackfulness
In contrast to a stackless coroutine a stackful
coroutine can be suspended from within a nested
stackframe. Execution resumes at exactly the same
point in the code where it was suspended before.

stackless
With a stackless coroutine, only the top-level routine
may be suspended. Any routine called by that top-level
routine may not itself suspend. This prohibits
providing suspend/resume operations in routines within
a general-purpose library.
https://www.boost.org/doc/libs/1_57_0/libs/coroutine/doc/html/coroutine/intro.html#coroutine.intro.stackfulness 


Mild Shock schrieb:
> Just watched 2 videos from Scala and the
> year 2023 and nearly chocked on my yoghurt,
> 
> especially when I saw the first presenter got a
> headeache from early returns. LoL
> 
> Async/Await for the Monadic Programmer
> https://www.youtube.com/watch?v=OH5cxLNTTPo
> 
> DIRECT STYLE SCALA Scalar Conference 2023
> https://www.youtube.com/watch?v=0Fm0y4K4YO8
> 
> Whats the bottom line: All because they discovered they
> could do async/await as well?

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

#13982

Its also proof of concept that no stack copying
is necessary. Well its not 100% true the Prolog
interpreter does a little bit unwind and rewind

during the '$YIELD'/1 instruction. But we do
nowhere copy some native stack, this is unlike
Martin Odersky's speculation, he might implement

someting with stack copying. Except that a virtual
threads might using a copying when they resize
their stack, I don't see any need for copying.

Also sometimes a callback can be piggy packed on
an existing coroutine if it doesn't yield itself,
I am already using this in Dogelog Player as an

optimization. The idea to use semaphores in my
implementation can be credited to this paper
from 1980 where semaphores are the main switchpoint:

Extension of Pascal and its Application to
Quasi-Parallel Programming and Simulation, Software -
Practice and Experience, 10 (1980), 773-789
J. Kriz and H. Sandmayr
https://www.academia.edu/47139332

But my experience with JDK 21 virtual threads
is still poor, I am only beginning to explore them
as a way to have a large number of coroutines.

Mild Shock schrieb:
> My revecent Async/Await surrogates for JDK 21
> provide coroutines with suspend/resume semantics.
> They are not continuations. They aim is to provide
> async/await and not only setTimeout().
> 
> As a result you don't need to write libraries
> with a continuation parameters. This is very unlike
> nonsense such as the JavaScript express web framework.
> 
> stackfulness
> In contrast to a stackless coroutine a stackful
> coroutine can be suspended from within a nested
> stackframe. Execution resumes at exactly the same
> point in the code where it was suspended before.
> 
> stackless
> With a stackless coroutine, only the top-level routine
> may be suspended. Any routine called by that top-level
> routine may not itself suspend. This prohibits
> providing suspend/resume operations in routines within
> a general-purpose library.
> https://www.boost.org/doc/libs/1_57_0/libs/coroutine/doc/html/coroutine/intro.html#coroutine.intro.stackfulness 
> 
> 
> Mild Shock schrieb:
>> Just watched 2 videos from Scala and the
>> year 2023 and nearly chocked on my yoghurt,
>>
>> especially when I saw the first presenter got a
>> headeache from early returns. LoL
>>
>> Async/Await for the Monadic Programmer
>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>
>> DIRECT STYLE SCALA Scalar Conference 2023
>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>
>> Whats the bottom line: All because they discovered they
>> could do async/await as well?
> 

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

#13983

Also the Kotlin language and runtime might suffer from
not enough "DIRECT STYLE" and even ignoring Doug Leas
java.util.concurrent.Flow, devlivering some bloated

redundant nonsense I speculate from glossing over it.
Flow has an interesting history. And all the new JDK 21
integrate HTTP server and HTTP client make use of

the interfaces bundled by the class Flow. But I am
tapping into it via ordinary InputStream and OutputStream.

Reactive Streams started as an initiative in late 2013
between engineers at Netflix, Pivotal and Lightbend.
Reactive Streams were proposed to become part of
Java 9 by Doug Lea, leader of JSR 166 as a new Flow
class that would include the interfaces currently
provided by Reactive Streams.
https://en.wikipedia.org/wiki/Reactive_Streams

Mild Shock schrieb:
> Its also proof of concept that no stack copying
> is necessary. Well its not 100% true the Prolog
> interpreter does a little bit unwind and rewind
> 
> during the '$YIELD'/1 instruction. But we do
> nowhere copy some native stack, this is unlike
> Martin Odersky's speculation, he might implement
> 
> someting with stack copying. Except that a virtual
> threads might using a copying when they resize
> their stack, I don't see any need for copying.
> 
> Also sometimes a callback can be piggy packed on
> an existing coroutine if it doesn't yield itself,
> I am already using this in Dogelog Player as an
> 
> optimization. The idea to use semaphores in my
> implementation can be credited to this paper
> from 1980 where semaphores are the main switchpoint:
> 
> Extension of Pascal and its Application to
> Quasi-Parallel Programming and Simulation, Software -
> Practice and Experience, 10 (1980), 773-789
> J. Kriz and H. Sandmayr
> https://www.academia.edu/47139332
> 
> But my experience with JDK 21 virtual threads
> is still poor, I am only beginning to explore them
> as a way to have a large number of coroutines.
> 
> Mild Shock schrieb:
>> My revecent Async/Await surrogates for JDK 21
>> provide coroutines with suspend/resume semantics.
>> They are not continuations. They aim is to provide
>> async/await and not only setTimeout().
>>
>> As a result you don't need to write libraries
>> with a continuation parameters. This is very unlike
>> nonsense such as the JavaScript express web framework.
>>
>> stackfulness
>> In contrast to a stackless coroutine a stackful
>> coroutine can be suspended from within a nested
>> stackframe. Execution resumes at exactly the same
>> point in the code where it was suspended before.
>>
>> stackless
>> With a stackless coroutine, only the top-level routine
>> may be suspended. Any routine called by that top-level
>> routine may not itself suspend. This prohibits
>> providing suspend/resume operations in routines within
>> a general-purpose library.
>> https://www.boost.org/doc/libs/1_57_0/libs/coroutine/doc/html/coroutine/intro.html#coroutine.intro.stackfulness 
>>
>>
>> Mild Shock schrieb:
>>> Just watched 2 videos from Scala and the
>>> year 2023 and nearly chocked on my yoghurt,
>>>
>>> especially when I saw the first presenter got a
>>> headeache from early returns. LoL
>>>
>>> Async/Await for the Monadic Programmer
>>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>>
>>> DIRECT STYLE SCALA Scalar Conference 2023
>>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>>
>>> Whats the bottom line: All because they discovered they
>>> could do async/await as well?
>>
> 

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

#13984

The struggle of cloud world domination is real:

They stole the golang syntax for send and recieve?
https://ballerina.io/why-ballerina/concurrent/

BTW: The original Tchaikovski's Swan Lake is here:

Tchaikovski's Swan Lake that was broadcasted
during August Coup in all Soviet television (collapse of USSR)
https://www.youtube.com/watch?v=Tj2c6vJvyPA

So ballerina.io wants to see Google golang collapse,
because its too Russian (founder Sergey Brin is Russian).

Ok, enough galopping horses. 

LoL

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

#13997

Can the golang interfaces handling be compared to lazy/sharing
in the non-strict semantics of Haskell? Just curious, maybe
there is nevertheless a chance to speed up Prolog call/n.

After all Haskell and Prolog are very similar they champion
non-strict features. Most novice Prolog programmers are
suprised by this behaviour, and that they need to invoke is/2,

making evaluation explicit, why is it not implicit like in every
other programming language (warning the example could
be misleading, its not what I am attacking, only motivation here):

?- X = 1+2.
X = 1+2

But then there are other more important corner where Prolog
and Haskell are basically the same, i.e. call/n.

The sharing in Haskell could then give semantic to monomorphic
and polymorphic caches. Did somebody write a paper about
golang interfaces handling, relating it to non-strict behaviour?


Mild Shock schrieb:
> Just watched 2 videos from Scala and the
> year 2023 and nearly chocked on my yoghurt,
> 
> especially when I saw the first presenter got a
> headeache from early returns. LoL
> 
> Async/Await for the Monadic Programmer
> https://www.youtube.com/watch?v=OH5cxLNTTPo
> 
> DIRECT STYLE SCALA Scalar Conference 2023
> https://www.youtube.com/watch?v=0Fm0y4K4YO8
> 
> Whats the bottom line: All because they discovered they
> could do async/await as well?

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

#13998

Motivation, it is now widespread assume that
Prolog has call/n. But testing shows that both
Scryer Prolog and Trealla Prolog chocke even on

call/1. But then we find this proposal which
includes maplist/n, foldl/4, etc..

A Prologue for Prolog - post-N290
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue

But is there a Prolog technology that makes
call/n fast in the first place?


Mild Shock schrieb:
> 
> Can the golang interfaces handling be compared to lazy/sharing
> in the non-strict semantics of Haskell? Just curious, maybe
> there is nevertheless a chance to speed up Prolog call/n.
> 
> After all Haskell and Prolog are very similar they champion
> non-strict features. Most novice Prolog programmers are
> suprised by this behaviour, and that they need to invoke is/2,
> 
> making evaluation explicit, why is it not implicit like in every
> other programming language (warning the example could
> be misleading, its not what I am attacking, only motivation here):
> 
> ?- X = 1+2.
> X = 1+2
> 
> But then there are other more important corner where Prolog
> and Haskell are basically the same, i.e. call/n.
> 
> The sharing in Haskell could then give semantic to monomorphic
> and polymorphic caches. Did somebody write a paper about
> golang interfaces handling, relating it to non-strict behaviour?
> 
> 
> Mild Shock schrieb:
>> Just watched 2 videos from Scala and the
>> year 2023 and nearly chocked on my yoghurt,
>>
>> especially when I saw the first presenter got a
>> headeache from early returns. LoL
>>
>> Async/Await for the Monadic Programmer
>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>
>> DIRECT STYLE SCALA Scalar Conference 2023
>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>
>> Whats the bottom line: All because they discovered they
>> could do async/await as well?
> 

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

#13999

BTW: I retract my claim that Trealla Prolog
chokes on call/1. This is amazing. Try this program:

?- [user].
p(X) :- X = (Y is 1+2, _ is Y+3).

First SWI-Prolog:

/* SWI-Prolog */
?- p(X), time((between(1,1000000,_),call(X),fail; true)).
% 2,999,998 inferences, 0.516 CPU in 0.508 seconds (101% CPU, 5818178 Lips)
X = (_A is 1+2, _ is _A+3).

?- time((between(1,1000000,_),p(X),call(X),fail; true)).
% 3,999,998 inferences, 0.594 CPU in 0.580 seconds (102% CPU, 6736839 Lips)

Then Trealla Prolog:

?- p(X), time((between(1,1000000,_),X,fail; true)).
% Time elapsed 0.244s, 4000003 Inferences, 16.363 MLips
    X = (_A is 1+2,_B is _A+3).

?- time((between(1,1000000,_),p(X),X,fail; true)).
% Time elapsed 0.399s, 6000003 Inferences, 15.047 MLips
    true.

Whats going on, why is it faster?

Mild Shock schrieb:
> 
> Motivation, it is now widespread assume that
> Prolog has call/n. But testing shows that both
> Scryer Prolog and Trealla Prolog chocke even on
> 
> call/1. But then we find this proposal which
> includes maplist/n, foldl/4, etc..
> 
> A Prologue for Prolog - post-N290
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue
> 
> But is there a Prolog technology that makes
> call/n fast in the first place?
> 
> 
> Mild Shock schrieb:
>>
>> Can the golang interfaces handling be compared to lazy/sharing
>> in the non-strict semantics of Haskell? Just curious, maybe
>> there is nevertheless a chance to speed up Prolog call/n.
>>
>> After all Haskell and Prolog are very similar they champion
>> non-strict features. Most novice Prolog programmers are
>> suprised by this behaviour, and that they need to invoke is/2,
>>
>> making evaluation explicit, why is it not implicit like in every
>> other programming language (warning the example could
>> be misleading, its not what I am attacking, only motivation here):
>>
>> ?- X = 1+2.
>> X = 1+2
>>
>> But then there are other more important corner where Prolog
>> and Haskell are basically the same, i.e. call/n.
>>
>> The sharing in Haskell could then give semantic to monomorphic
>> and polymorphic caches. Did somebody write a paper about
>> golang interfaces handling, relating it to non-strict behaviour?
>>
>>
>> Mild Shock schrieb:
>>> Just watched 2 videos from Scala and the
>>> year 2023 and nearly chocked on my yoghurt,
>>>
>>> especially when I saw the first presenter got a
>>> headeache from early returns. LoL
>>>
>>> Async/Await for the Monadic Programmer
>>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>>
>>> DIRECT STYLE SCALA Scalar Conference 2023
>>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>>
>>> Whats the bottom line: All because they discovered they
>>> could do async/await as well?
>>
> 

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

#14000

I can make the first test case faster in SWI-Prolog
by removing the call/1. but it doesn't have an impact
on the second test case:

?- p(X), time((between(1,1000000,_),X,fail; true)).
% 2,999,998 inferences, 0.172 CPU in 0.183 seconds (94% CPU, 17454534 Lips)
X = (_A is 1+2, _ is _A+3).

?- time((between(1,1000000,_),p(X),X,fail; true)).
% 3,999,998 inferences, 0.594 CPU in 0.597 seconds (99% CPU, 6736839 Lips)
true.

Now I am testing the same for SWI-Prolog and Trealla
Prolog. SWI-Prolog has it an itch faster in the first
test case, but an itch slower in the second test case.

Mild Shock schrieb:
> 
> BTW: I retract my claim that Trealla Prolog
> chokes on call/1. This is amazing. Try this program:
> 
> ?- [user].
> p(X) :- X = (Y is 1+2, _ is Y+3).
> 
> First SWI-Prolog:
> 
> /* SWI-Prolog */
> ?- p(X), time((between(1,1000000,_),call(X),fail; true)).
> % 2,999,998 inferences, 0.516 CPU in 0.508 seconds (101% CPU, 5818178 Lips)
> X = (_A is 1+2, _ is _A+3).
> 
> ?- time((between(1,1000000,_),p(X),call(X),fail; true)).
> % 3,999,998 inferences, 0.594 CPU in 0.580 seconds (102% CPU, 6736839 Lips)
> 
> Then Trealla Prolog:
> 
> ?- p(X), time((between(1,1000000,_),X,fail; true)).
> % Time elapsed 0.244s, 4000003 Inferences, 16.363 MLips
>     X = (_A is 1+2,_B is _A+3).
> 
> ?- time((between(1,1000000,_),p(X),X,fail; true)).
> % Time elapsed 0.399s, 6000003 Inferences, 15.047 MLips
>     true.
> 
> Whats going on, why is it faster?
> 
> Mild Shock schrieb:
>>
>> Motivation, it is now widespread assume that
>> Prolog has call/n. But testing shows that both
>> Scryer Prolog and Trealla Prolog chocke even on
>>
>> call/1. But then we find this proposal which
>> includes maplist/n, foldl/4, etc..
>>
>> A Prologue for Prolog - post-N290
>> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue
>>
>> But is there a Prolog technology that makes
>> call/n fast in the first place?
>>
>>
>> Mild Shock schrieb:
>>>
>>> Can the golang interfaces handling be compared to lazy/sharing
>>> in the non-strict semantics of Haskell? Just curious, maybe
>>> there is nevertheless a chance to speed up Prolog call/n.
>>>
>>> After all Haskell and Prolog are very similar they champion
>>> non-strict features. Most novice Prolog programmers are
>>> suprised by this behaviour, and that they need to invoke is/2,
>>>
>>> making evaluation explicit, why is it not implicit like in every
>>> other programming language (warning the example could
>>> be misleading, its not what I am attacking, only motivation here):
>>>
>>> ?- X = 1+2.
>>> X = 1+2
>>>
>>> But then there are other more important corner where Prolog
>>> and Haskell are basically the same, i.e. call/n.
>>>
>>> The sharing in Haskell could then give semantic to monomorphic
>>> and polymorphic caches. Did somebody write a paper about
>>> golang interfaces handling, relating it to non-strict behaviour?
>>>
>>>
>>> Mild Shock schrieb:
>>>> Just watched 2 videos from Scala and the
>>>> year 2023 and nearly chocked on my yoghurt,
>>>>
>>>> especially when I saw the first presenter got a
>>>> headeache from early returns. LoL
>>>>
>>>> Async/Await for the Monadic Programmer
>>>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>>>
>>>> DIRECT STYLE SCALA Scalar Conference 2023
>>>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>>>
>>>> Whats the bottom line: All because they discovered they
>>>> could do async/await as well?
>>>
>>
> 

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

#14001

But I cannot retract my claim about Scryer Prolog
it definitively chokes:

?- p(X), time((between(1,1000000,_),X,fail; true)).
    % CPU time: 2.233s, 11_000_023 inferences
    X = (_A is 1+2,_B is _A+3).

?- time((between(1,1000000,_),p(X),X,fail; true)).
    % CPU time: 6.180s, 13_000_045 inferences
    true.

Thats an order slower than Trealla and SWI-Prolog.

Mild Shock schrieb:
> I can make the first test case faster in SWI-Prolog
> by removing the call/1. but it doesn't have an impact
> on the second test case:
> 
> ?- p(X), time((between(1,1000000,_),X,fail; true)).
> % 2,999,998 inferences, 0.172 CPU in 0.183 seconds (94% CPU, 17454534 Lips)
> X = (_A is 1+2, _ is _A+3).
> 
> ?- time((between(1,1000000,_),p(X),X,fail; true)).
> % 3,999,998 inferences, 0.594 CPU in 0.597 seconds (99% CPU, 6736839 Lips)
> true.
> 
> Now I am testing the same for SWI-Prolog and Trealla
> Prolog. SWI-Prolog has it an itch faster in the first
> test case, but an itch slower in the second test case.
> 
> Mild Shock schrieb:
>>
>> BTW: I retract my claim that Trealla Prolog
>> chokes on call/1. This is amazing. Try this program:
>>
>> ?- [user].
>> p(X) :- X = (Y is 1+2, _ is Y+3).
>>
>> First SWI-Prolog:
>>
>> /* SWI-Prolog */
>> ?- p(X), time((between(1,1000000,_),call(X),fail; true)).
>> % 2,999,998 inferences, 0.516 CPU in 0.508 seconds (101% CPU, 5818178 
>> Lips)
>> X = (_A is 1+2, _ is _A+3).
>>
>> ?- time((between(1,1000000,_),p(X),call(X),fail; true)).
>> % 3,999,998 inferences, 0.594 CPU in 0.580 seconds (102% CPU, 6736839 
>> Lips)
>>
>> Then Trealla Prolog:
>>
>> ?- p(X), time((between(1,1000000,_),X,fail; true)).
>> % Time elapsed 0.244s, 4000003 Inferences, 16.363 MLips
>>     X = (_A is 1+2,_B is _A+3).
>>
>> ?- time((between(1,1000000,_),p(X),X,fail; true)).
>> % Time elapsed 0.399s, 6000003 Inferences, 15.047 MLips
>>     true.
>>
>> Whats going on, why is it faster?
>>
>> Mild Shock schrieb:
>>>
>>> Motivation, it is now widespread assume that
>>> Prolog has call/n. But testing shows that both
>>> Scryer Prolog and Trealla Prolog chocke even on
>>>
>>> call/1. But then we find this proposal which
>>> includes maplist/n, foldl/4, etc..
>>>
>>> A Prologue for Prolog - post-N290
>>> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/prologue
>>>
>>> But is there a Prolog technology that makes
>>> call/n fast in the first place?
>>>
>>>
>>> Mild Shock schrieb:
>>>>
>>>> Can the golang interfaces handling be compared to lazy/sharing
>>>> in the non-strict semantics of Haskell? Just curious, maybe
>>>> there is nevertheless a chance to speed up Prolog call/n.
>>>>
>>>> After all Haskell and Prolog are very similar they champion
>>>> non-strict features. Most novice Prolog programmers are
>>>> suprised by this behaviour, and that they need to invoke is/2,
>>>>
>>>> making evaluation explicit, why is it not implicit like in every
>>>> other programming language (warning the example could
>>>> be misleading, its not what I am attacking, only motivation here):
>>>>
>>>> ?- X = 1+2.
>>>> X = 1+2
>>>>
>>>> But then there are other more important corner where Prolog
>>>> and Haskell are basically the same, i.e. call/n.
>>>>
>>>> The sharing in Haskell could then give semantic to monomorphic
>>>> and polymorphic caches. Did somebody write a paper about
>>>> golang interfaces handling, relating it to non-strict behaviour?
>>>>
>>>>
>>>> Mild Shock schrieb:
>>>>> Just watched 2 videos from Scala and the
>>>>> year 2023 and nearly chocked on my yoghurt,
>>>>>
>>>>> especially when I saw the first presenter got a
>>>>> headeache from early returns. LoL
>>>>>
>>>>> Async/Await for the Monadic Programmer
>>>>> https://www.youtube.com/watch?v=OH5cxLNTTPo
>>>>>
>>>>> DIRECT STYLE SCALA Scalar Conference 2023
>>>>> https://www.youtube.com/watch?v=0Fm0y4K4YO8
>>>>>
>>>>> Whats the bottom line: All because they discovered they
>>>>> could do async/await as well?
>>>>
>>>
>>
> 

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

#14002

A small sanity test. How does formerly Jekejeke Prolog
and Dogelog Player perform. Dogelog Player has not yet
call/N, I do not promote using it, since I am

still waiting for a good idea to compile it a little
bit more statically. Formerly Jekejeke Prolog uses a
dynamic inline cache, polymorphic in the arity.

But this test case is anyway less about call/N and
more about call/1 and is/2. I get:

For formerly Jekejeke Prolog:

/* Jekejeke Prolog 1.6.6 */
?- p(X), time((between(1,1000000,_),X,fail; true)).
% Zeit 540 ms, GC 3 ms, Uhr 01.03.2024 19:37
X = (_0 is 1+2, _1 is _0+3).

?- time((between(1,1000000,_),p(X),X,fail; true)).
% Zeit 867 ms, GC 3 ms, Uhr 01.03.2024 19:37
true.

For Dogelog Player:

/* Dogelog Player 1.1.6 */
?- p(X), time((between(1,1000000,_),X,fail; true)).
% Zeit 447 ms, GC 0 ms, Lips 15660199, Uhr 01.03.2024 19:38
X = (_16030782 is 1+2, _16030783 is _16030782+3).

?- time((between(1,1000000,_),p(X),X,fail; true)).
% Zeit 1780 ms, GC 0 ms, Lips 14606802, Uhr 01.03.2024 19:38
true.

Jekejeke Prolog and Dogelog Player do not choke
like Scryer Prolog does. The performance of Dogelog
Player is amazing, since call/1 is implemented in

pure Prolog, not via an interpreter, but via a little
compiler, and an intermediate form, that we anyway use
when we generate cross compiled code or

static/dynamic clausse.

Mild Shock schrieb:
> But I cannot retract my claim about Scryer Prolog
> it definitively chokes:
> 
> ?- p(X), time((between(1,1000000,_),X,fail; true)).
>     % CPU time: 2.233s, 11_000_023 inferences
>     X = (_A is 1+2,_B is _A+3).
> 
> ?- time((between(1,1000000,_),p(X),X,fail; true)).
>     % CPU time: 6.180s, 13_000_045 inferences
>     true.
> 
> Thats an order slower than Trealla and SWI-Prolog.
> 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web