Path: csiph.com!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Mild Shock <janburse@fastmail.fm>
Newsgroups: comp.lang.javascript
Subject: AOT Lambdas in Dogelog Player (Was: Arrow Functions in Dogelog Player)
Date: Sun, 26 Oct 2025 15:54:43 +0100
Message-ID: <10dlcni$k47f$1@solani.org>
References: <10bltn3$dk1e$2@solani.org> <10cemgn$t6kn$2@solani.org> <10ctaj0$1615t$3@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 26 Oct 2025 14:54:42 -0000 (UTC)
Injection-Info: solani.org; logging-data="659695"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 SeaMonkey/2.53.21
Cancel-Lock: sha1:gfs2fIthf6G7g9ZXNz/iaoyWoXo=
In-Reply-To: <10ctaj0$1615t$3@solani.org>
X-User-ID: eJwFwYEBwDAEBMCV8PgYJ2j2H6F3gdQcekZ6vHhUPRBKb9sAbtvV5dS9xSfak8KGq59I0L5jUriy9K1R+wEq2BQy
Xref: csiph.com comp.lang.javascript:124412


Dogelog Player is a Prolog system written
in 100% Prolog. We recently made a stab at
arrow functions via an operator (=>)/2. The
semantics is based on the witness calculation
as found in the ISO core standard 7.1.1.4.
As promised we show their ahead of
time (AOT) compilation.

We didn’t find AOT compilation of lambda
expression in Scryer Prolog. The Dogelog
Player overhead of witness calculation
disappears through AOT compilation, since
its done once at compile time. Comparison with
the AOT lambdas of SWI-Prolog shows a similar
speed-up of a factor 7x.

See also:

AOT Lambdas in Dogelog Player
https://medium.com/2989/063d4abd8c17

Mild Shock schrieb:
> Hi,
> 
> Dogelog Player is a 100% Prolog written Prolog
> system for the JavaScript, Python and Java platform.
>  From its inception we let most of the higher order
> logic programming rest in limbo. Only recently we
> added call/n and maplist/n, foldl/n, etc..
> 
> The upcoming release will see the introduction of
> arrow functions via (=>)/2 and filter/3, etc..
> JavaScript programmers might be familiar with the
> concept, only our arrow functions are boolean
> arrow functions driven by the outcome of a goal.
> 
> Diverting from library(yall) of Logtalk provenance,
> the syntax and semantic of our arrow functions matches
> that of JavaScript. To speed up loop processing we have
> already a runtime preprocessing in place. The future
> might bring refinements, such as ahead of time
> 
> compilation into Albufeira anonymous predicates.
> 
> Bye
> 
> See also:
> 
> Arrow Functions in Dogelog Player
> https://qiita.com/j4n_bur53/items/eff987ced7b0d0c267e9
> 
> Mild Shock schrieb:
>>
>> We present a Prolog transducer dubbed NetFish
>> that can be used to translate Java code into C#
>> code. NetFish can be built with a non-standard
>> version of DCG, extending the notion of semi-context
>> from terminals to non-terminals. NetFish can be
>> easily run over arbitrary long files
>> with little memory.
>>
>> NetFish uses a sliding window along an input text.
>> It then applies the given compiled DSL rules in a
>> cascading style. We used various LLMs such as
>> ChatGPT and DeepSeek to advice us in the rules,
>> but such a process is currently not integrated.
>> The output can be run with .NET 9.0.
>>
>> See also:
>>
>> NetFish Transducer in Dogelog Player
>> https://medium.com/2989/9d392937c1e3
>>
>> Mild Shock schrieb:
>>> Dear All,
>>>
>>> We are happy to announce a new edition
>>> of the Dogelog Player:
>>>
>>> - Enhanced GC:
>>> To lift the native stack limitations, we
>>> opted for a marking algorithm based on
>>> Peter Deutschs algorithm E as found in
>>> Donald Knuths "The Art of Computing Programming"
>>> book. Our variant uses an int field that was
>>> anyway recently introduced for Prolog
>>> compound coloring, so that no extra space
>>> was introduced in this release.
>>>
>>> - Enhanced Binary-Ops:
>>> By adopting the pointer approach from Jaffar's
>>> Unification we could get rid of the map based
>>> realization from previous releases for union
>>> find. It turns out this gives quite a speed
>>> advantage. We also lifted the native stack
>>> limitation by using an extra space in the
>>> form of a stack and a log, which surprisingly
>>> performs well especially for Java, less for
>>> JavaScript and Python.
>>>
>>> - Enhanced Unary-Ops:
>>> For unary operations such as term_variables/2,
>>> ground/1, etc.. we experimented with both
>>> Peter Deutsch and a stack / log approaches.
>>> Interestingly for performance reasons we had
>>> to dismiss the two phase approach induced by
>>> a marking algorithm such as Peter Deutsch,
>>> and went also with the one phase approach as
>>> offered by a stack / log realization.
>>>
>>> Have Fun!
>>>
>>> Jan Burse, 02.10.2025, https://www.herbrand.ai/
>>
>