Re: Can we trust the Scryer Prolog Gurus? (Was: A harsh wind is blowing into the face of Prolog now… )

Well I am mistaken, Prolog 0 must have had some
concept of error. For example I find:
3. OPERATION SUR LES NOMBRES
=============================
LES PREDICATS SONT EVALUES A ERROR
And this is also used in a code_type variant, i.e.
CHIFFRE and LETTRE, follow the instantiation error
idea. But we have this also in Prolog systems today:
/* SWI-Prolog */
?- code_type(0'a, X).
X = alnum .
?- code_type(X, X).
ERROR: Arguments are not sufficiently instantiated
It is not the case that modern Prolog systems always
silently fail. They silently fail in atom/1, integer/1, etc..
which makes sense, especially from a WAM implementation
viewpoint, since WAM has usually type tag branching or
switching instructions. So these atom/1, integer/1, etc.. can
be implemented quite efficiently and one should view them
as belonging to the same category as var/1, (==)/2, etc..
i.e. meta predicates that deal syntactically with Prolog terms.
Some Prolog system can even perform indexing on these guards.
Mild Shock schrieb:

That the DEC 10 Prolog 1975 is close to Prolog 0,
can be verified by reading the Prolog 0 manual:
 MANUEL DE REFE RE NeE ET D'UTILISATION - PROLOG
ROUSSEL Ph. (1975)
http://alain.colmerauer.free.fr/alcol/ArchivesPublications/ManuelProlog/Pr.pdf   So at that same year there was already an
English rip-off. If I read the french, I also
don't find some atom/1, integer/1 equivalent
 that would throw an instantiation error. Problem
is again, what would have been an exception in Prolog 0?
 Mild Shock schrieb:

For example one Guru claimed?
>
 > Prolog were invented today, I think there would
 > be at least two significant differences:
 >
 > First, the type-testing predicates like atom/1,
 > integer/1 and compound/1 would (and should) throw
 > instantiation errors if their arguments are not
 > sufficiently instantiated.
 >
 > This is also what the original versions of Prolog
 > did. However, DEC 10 Prolog chose to replace instantiation
 > errors by silent failures, and this has been
 > perpetuated in the Edinburgh tradition for type tests
 > including the ISO standard.
https://www.quora.com/If-prolog-were-being-invented-today-with-no-concern-for-backward-compatibility-or-the-existing-standardization-how-would-it-differ-from-standard-prolog >
>
I cannot verify any of the above nonsense.
>
First of all the term "DEC-10 Prolog" is ambigious:
>
DEC 10 Prolog 1975
https://www.softwarepreservation.org/projects/prolog/prolog/edinburgh/doc/Warren-Epilog_400_400-1975.pdf >
>
DEC 10 Prolog 1982
https://userweb.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf >
>
The DEC 10 Prolog 1975 looks very close to Prolog 0
with its french predicate names. There is not a simgle
atom/1, integer/1 equivalent that would throw an
>
instantiation error. Actually Prolog 0 didn't even
have some sort of exceptions, right?
>
Mild Shock schrieb:

Especially since good old FORTRAN has
made a new appearance:
>
TIOBE Index for May 2024
I have received a lot of questions why Fortran entered the top 10
again after more than 20 years. The TIOBE index just publishes
what has been measured.
https://www.tiobe.com/tiobe-index/
>
Why Fortran is back in TIOBE’s top 10
First, Fortran is especially good at numerical analysis and
computational mathematics. Numerical and mathematical
computing is growing because interest in artificial intelligence
is growing, Jansen told TechRepublic in an email.
https://www.techrepublic.com/article/tiobe-index-may-2024/

>