• Focus on Prolog language is better than focus on Prolog engine (Was: Gu

    From Mild Shock@21:1/5 to Mild Shock on Sun Nov 24 12:47:47 2024
    Hi,

    How good does the GNU Prolog Novacore adapter
    score? It scores more badly in the test suite
    that tests the libraries since it also tests the

    web client and server functionality:

    Folder gnu j js py cnt
    calculate 42 136 136 136 136
    common 88 175 175 173 175
    extend 117 134 134 133 134
    Total 247 445 445 442 445

    But the GNU Prolog Novacore adapter fares
    quite well in the core testing itself, where
    not some libraries are tested:

    Folder gnu j js py cnt
    arithmetic 215 225 224 224 225
    control 159 171 171 171 171
    extra 45 127 127 123 127
    stream 62 84 83 84 85
    structure 222 229 229 229 229
    Total 703 836 834 831 837

    Bye

    Mild Shock schrieb:
    Hi,

    I don't feel adressed by you critique. Since I
    think the idea of an Prolog engine is the wrong
    approach. The idea should be a Prolog language,

    like the ISO core standard. SWI-Prolog did everything
    to be different and better from the ISO core standard.
    And ended up with a bloathed engine that runs

    non-portable code. I did a little bit the same error
    with formerly Jekejeke Prolog, it did not pay attention
    to apply the KISS principle:

    https://en.wikipedia.org/wiki/KISS_principle

    If would continue developing formerly Jekejeke Prolog
    as I did in the past, I would introduce a module
    class loader with advent of JDK 9, which would give

    an additional layer of grouping to the Prolog modules.
    Dogelog Player tries to do something else with its
    Novacore. It tries to minimize the Prolog language

    implemented by the Prolog engine. If you develop against
    an idea of a Prolog language and not against an idea of
    a Prolog engine, chances are higher that stay agile and

    can easily switch Prolog engines, and protect your investment.

    Bye

    P.S.: Also with novacore its very hard. I wrote an
    Novacore adapter for GNU Prolog:

    https://www.novacuor.ch/srctab/doclet/docs/07_envir/adapter/gnu/package.html


    But all Unicode test cases fail. Since GNU Prolog
    cannot do Unicode.

    But Unicode is part of Novacore.

    Julio Di Egidio schrieb:
    On 24/11/2024 04:25, Mild Shock wrote:

    You want a GNU license, still you can demonstrate
    that GNU licensing system failed in the case of
    GNU Prolog to create a vital community especially

    I just need a product that works properly, that isn't just spaghetti
    code at all levels, and from a team/company that doesn't pull the rug,
    or sabotages, or black mails me as soon as I am invested enough.  I
    could even pay for that, as we used to do for technology when software
    and developing software was still a professional endeavour.  And GNU
    has little to do with any failure, except the failure of humanity that
    humanity is: rather everybody is an MS/Google/Monsanto employee by now.

    an interesting fork somewhere that supported Unicode.

    That Unicode even enters these discussions is a joke.  I'll just end
    up writing my own Prolog engine: a GPL-licensed Prolog engine in
    JS/Wasm, and an open project proper.  Or maybe I'll just switch to
    Mizar...  You stay tuned: next black Friday.

    -Julio



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mild Shock@21:1/5 to Mild Shock on Sun Nov 24 13:05:00 2024
    Hi,

    Example that violates KISS: https://prolog-lang.org/ImplementersForum/0105-write-options.html

    In Novacore, I have only introduced two new
    write options priority/1 and format/1. They are
    releavant for answer substitution display
    and listing/1 formatting.

    My deepest whish is for example to have
    format/1 not as part of the core write options.
    But this is very difficult to archive.
    Should listing/1 sit in its own library,

    and have a clone of the write routine? Its
    easier to enhance the existing write routine
    in the core and add some format/1 logic,
    than have two write routines.

    Quite a annonying problem to solve this
    separation of concern. But maybe I should try
    again, and can move listing/1 together with
    format/1 write option into a separate library

    that is not part of the core? Who knows...

    Bye

    P.S.: Some Prolog systems have do not have a listing/1
    implementation. Try doing listing/1 in Scryer Prolog,
    last time I looked they didn't have such a built-in.

    Mild Shock schrieb:
    Hi,

    How good does the GNU Prolog Novacore adapter
    score? It scores more badly in the test suite
    that tests the libraries since it also tests the

    web client and server functionality:

    Folder    gnu    j    js    py    cnt
    calculate    42    136    136    136    136
    common    88    175    175    173    175
    extend    117    134    134    133    134
    Total    247    445    445    442    445

    But the GNU Prolog Novacore adapter fares
    quite well in the core testing itself, where
    not some libraries are tested:

    Folder    gnu    j    js    py    cnt
    arithmetic    215    225    224    224    225
    control    159    171    171    171    171
    extra    45    127    127    123    127
    stream    62    84    83    84    85
    structure    222    229    229    229    229
    Total    703    836    834    831    837

    Bye

    Mild Shock schrieb:
    Hi,

    I don't feel adressed by you critique. Since I
    think the idea of an Prolog engine is the wrong
    approach. The idea should be a Prolog language,

    like the ISO core standard. SWI-Prolog did everything
    to be different and better from the ISO core standard.
    And ended up with a bloathed engine that runs

    non-portable code. I did a little bit the same error
    with formerly Jekejeke Prolog, it did not pay attention
    to apply the KISS principle:

    https://en.wikipedia.org/wiki/KISS_principle

    If would continue developing formerly Jekejeke Prolog
    as I did in the past, I would introduce a module
    class loader with advent of JDK 9, which would give

    an additional layer of grouping to the Prolog modules.
    Dogelog Player tries to do something else with its
    Novacore. It tries to minimize the Prolog language

    implemented by the Prolog engine. If you develop against
    an idea of a Prolog language and not against an idea of
    a Prolog engine, chances are higher that stay agile and

    can easily switch Prolog engines, and protect your investment.

    Bye

    P.S.: Also with novacore its very hard. I wrote an
    Novacore adapter for GNU Prolog:

    https://www.novacuor.ch/srctab/doclet/docs/07_envir/adapter/gnu/package.html >>

    But all Unicode test cases fail. Since GNU Prolog
    cannot do Unicode.

    But Unicode is part of Novacore.

    Julio Di Egidio schrieb:
    On 24/11/2024 04:25, Mild Shock wrote:

    You want a GNU license, still you can demonstrate
    that GNU licensing system failed in the case of
    GNU Prolog to create a vital community especially

    I just need a product that works properly, that isn't just spaghetti
    code at all levels, and from a team/company that doesn't pull the
    rug, or sabotages, or black mails me as soon as I am invested
    enough.  I could even pay for that, as we used to do for technology
    when software and developing software was still a professional
    endeavour.  And GNU has little to do with any failure, except the
    failure of humanity that humanity is: rather everybody is an
    MS/Google/Monsanto employee by now.

    an interesting fork somewhere that supported Unicode.

    That Unicode even enters these discussions is a joke.  I'll just end
    up writing my own Prolog engine: a GPL-licensed Prolog engine in
    JS/Wasm, and an open project proper.  Or maybe I'll just switch to
    Mizar...  You stay tuned: next black Friday.

    -Julio




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)