jvms7 is full of Prolog

[Jan Burse]

Dear All,

"Wei Tao, together with Frank Yellin, Tim Lindholm, and Gilad Bracha,
implemented the Prolog verifier that formed the basis for the
specification in both Java ME and Java SE. Wei then implemented the
specification "for real" in the HotSpot JVM."

"The type checker enforces type rules that are specified by means of
Prolog clauses. English language text is used to describe the type rules
in an informal way, while the Prolog clauses provide a formal
specification."

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

[rupert...@googlemail.com]

I never knew. Thanks for posting.

I'm using Prolog to generate Java code for fairly standard REST services on top of a relational database. Next time someone suggests that I should use something other than Prolog, or that my choice of language is somehow wilfully obscure, I will point them at this.

Rupert

[rupert...@googlemail.com]

On Tuesday, March 24, 2015 at 1:11:26 PM UTC, Jan Burse wrote:

BTW, Does this mean there is a Prolog interpreter built into the JVM or the compiler? If I knew where to look in the com.sun.* packages would I find it? Or were these rules perhaps compiled to C through GnuProlog or similar?

Rupert

[Jan Burse]

Hi,

Dunno. I found this via twitter @progopedia.
It seem to have been first noticed on reddit:


http://www.reddit.com/r/prolog/comments/301oeu/the_java_vm_specification_contains_a_lot_of_prolog/

I would say most likely Prolog predicate calls such as:

xxx(obj,arg1,..,argn,res)

Where turned into Java method calls by Wei and others:

res = obj.xxx(arg1,..argn)

But this is just a speculation.

Bye

rupert...@googlemail.com schrieb:

[rupert...@googlemail.com]

Could it be this:

http://www.gnu.org/software/gnuprologjava/

I didn't know there was a Java version of Gnu prolog till now.

Rupert

[Jan Burse]

rupert...@googlemail.com schrieb:

> Could it be this:
>
> http://www.gnu.org/software/gnuprologjava/
>
> I didn't know there was a Java version of Gnu prolog till now.
>
> Rupert

I am not convinced that any Prolog compiler
was involved. I read:

"Later, Mingyao Yang improved the design and
specification, and implemented the final version
that shipped in the Reference Implementation of
Java SE 6. The specification also benefited from
the efforts of the JSR 202 Expert Group: Peter
Burka, Alessandro Coglio, Sanghoon Jin, Christian
Kemper, Larry Rau, Eva Rose, and Mark Stolz."

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

So I really take it, that Prolog was used as
a specification, but not as an executable specification,
but simply as a sweat specification, to manually
implement something.

But its difficult to find some source code of the
verifier. I tried a little bit just now, but wasn't
able. Also there is kind of a diversity of verifiers,
see for example:

Java bytecode verification: algorithms and formalizations
Xavier Leroy
INRIA Rocquencourt and Trusted Logic S.A.
Xavier...@inria.fr

http://www-master.ufr-info-p6.jussieu.fr/2005/IMG/pdf/leroy-bytecode-verification-JAR.pdf

Bye

[Jan Burse]

Jan Burse schrieb:

> So I really take it, that Prolog was used as
> a specification, but not as an executable specification,
> but simply as a sweat specification, to manually
> implement something.

It seems that there was a transition from type inference
to type checking. I guess for performance reasons.
I assume that type inference is more costly than
type checking based on extra information.

The extra information seems to be the stack maps:

"4.10.1 Verification by Type Checking
A class file whose version number is greater than or
equal to 50.0 (§4.1) must be verified using the type
checking rules given in this section. If, and only if,
a class file's version number equals 50.0, then if
the type checking fails, a Java Virtual Machine implementation
may choose to attempt to perform verification by type
inference (§4.10.2).

This is a pragmatic adjustment, designed to ease the
transition to the new verification discipline. Many
tools that manipulate class files may alter the
bytecodes of a method in a manner that requires
adjustment of the method's stack map frames. If a
tool does not make the necessary adjustments to the
stack map frames, type checking may fail even
4.10 Verification of class Files though the bytecode
is in principle valid (and would consequently verify
under the old type inference scheme).

To allow implementors time to adapt their tools, Java
Virtual Machine implementations may fall back to the
older verification discipline, but only for a limited
time. In cases where type checking fails but type inference
is invoked and succeeds, a certain performance penalty is
expected. Such a penalty is unavoidable. It also should
serve as a signal to tool vendors that their output
needs to be adjusted, and provides vendors with additional
incentive to make these adjustments.

In summary, failover to verification by type inference
supports both the gradual addition of stack map
frames to the Java SE platform (if they are not present
in a version 50.0 class file, failover is allowed) and
the gradual removal of the jsr and jsr_w instructions
from the Java SE platform (if they are present in a
version 50.0 class file, failover is allowed)."

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

[Julio Di Egidio]

<rupert...@googlemail.com> wrote in message
news:64542e69-4d59-4dcd...@googlegroups.com...

I too was excited, eventually Prolog on my CV would have made sense...

It is indeed unfortunate that nobody with the resources finds the time or
intent to provide Prolog as an actually available tool for software
engineering "at large" (I build business systems in .NET), but, IMHO, the
limit here is all and only in the big players' strategy.

For example, I have tried myself few years ago to implement a
production-level WAM-based Prolog engine for .NET, but I just had to give
up: neither MS seems interested into documenting the DLR (Prolog could
easily be a 1st class .NET dynamic language), nor a conformant (in fact, an
ever quasi-conformant) Prolog parser can be built by a single human being in
a single life time, above all if the guy in question has got bills to pay
out of some other "real" job...

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> For example, I have tried myself few years ago to implement a
> production-level WAM-based Prolog engine for .NET, but I just had to
> give up: neither MS seems interested into documenting the DLR (Prolog
> could easily be a 1st class .NET dynamic language), nor a conformant (in
> fact, an ever quasi-conformant) Prolog parser can be built by a single
> human being in a single life time, above all if the guy in question has
> got bills to pay out of some other "real" job...

See file parse_supp.c:

static WamWord
Parse_Term(int cur_prec, int context, Bool comma_is_punct)

In archive gprolog-1.4.4.tar.gz at:

http://sourceforge.net/projects/gprolog/files/1.4.4/

It has an LGPL license.

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message
news:mf52i8$78t$1...@news.albasani.net...

Yes, that may very well solve one problem, although it is not necessarily an
"easy" solution: I'd have to inspect the code to say for sure, but while one
can compile C directly in a C/C++ .NET project, it may still be non-trivial
work to make it conform to managed-language (CLR) constraints.

There is also another point I have not taken the time to verify: whether
that parser is dependent on (specific to)
WAM in any way, as I certainly would not want that dependency.

Anyway, as said, thanks for the reminder: that is a very good starting point
in any case.

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> There is also another point I have not taken the time to verify: whether
> that parser is dependent on (specific to)
> WAM in any way, as I certainly would not want that dependency.

I take it as an urban myth that a Prolog parser
is extremly different. You can browse the
parser online:

http://sourceforge.net/p/gprolog/code/ci/457f7b447c2b9e90a09956ff15fd277d269b1d98/tree/src/BipsPl/parse_supp.c#l295

It uses a WAM specific idiom to create structures
and the like. The idiom is PL_Put_xxx followed
by PL_Unify_Values.

For example there is a helper:

Create_Structure(int func, int arity, WamWord *arg)
{
WamWord res_word;
int i;
if (arity == 2 && func == ATOM_CHAR('.'))
{
res_word = Pl_Put_List();
Pl_Unify_Value(arg[0]);
Pl_Unify_Value(arg[1]);
}
else
{
res_word = Pl_Put_Structure(func, arity);
for (i = 0; i < arity; i++)
Pl_Unify_Value(arg[i]);
}
return res_word;
}

[Jan Burse]

Jan Burse schrieb:
> is extremly different.
is extremly difficult.

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mf5u8i$7df$1...@news.albasani.net...

> Julio Di Egidio schrieb:
>
>> There is also another point I have not taken the time to verify: whether
>> that parser is dependent on (specific to)
>> WAM in any way, as I certainly would not want that dependency.
>
> I take it as an urban myth that a Prolog parser

> is extremly [difficult].

Just try, a fully conformant parser. But there are of course plenty of
parser generators: the difficulty is all in writing the grammar... I spent
several weeks at the time with Antlr and I just could not get to the bottom
of it (I am not an expert parser writer, anyway). Not to mention that the
standard language spec is not even fully self-consistent, but that is
another story: the extreme complexity of the language grammar would anyway
be there.

> You can browse the parser online:
> http://sourceforge.net/p/gprolog/code/ci/457f7b447c2b9e90a09956ff15fd277d269b1d98/tree/src/BipsPl/parse_supp.c#l295
>
> It uses a WAM specific idiom to create structures
> and the like. The idiom is PL_Put_xxx followed
> by PL_Unify_Values.

I would just not want to couple the parser with the implementation, nor I
would nowadays implement a Prolog engine based on the WAM. So, it is a pity
if that parser outputs a WAM-specific syntax tree (and indeed it appears it
does): OTOH, I'd guess that parser was itself generated from a grammar...?

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> I would just not want to couple the parser with the implementation, nor
> I would nowadays implement a Prolog engine based on the WAM. So, it is
> a pity if that parser outputs a WAM-specific syntax tree (and indeed it
> appears it does): OTOH, I'd guess that parser was itself generated from
> a grammar...?

Not really.

Its just a hand-written deterministic recursive decend
parser. It might be derived from a specification, but
it is not an executable specification, again if there
was any spacification, it was used as a sweat specification.

Also it is not specially tied to WAM. You can replace
helper functions such as create_compound by your own
functions, that generate the parsed term in your own
data structure. Whatever this might be.

Bye

P.S.: BTW the specification itself isn't that
troublesome, you find it for example in the DEC10
Prolog manual, it is really simple:

I.7.3. Syntax of Terms as Tokens

term-read-in --> subterm(1200) full-stop

subterm(N) --> term(M)
{ where M is less than or equal to N }

term(N) --> op(N,fx)
| op(N,fy)
| op(N,fx) subterm(N-1)
{ except the case '-' number }
{ if subterm starts with a '(',
op must be followed by a space }
| op(N,fy) subterm(N)
{ if subterm starts with a '(',
op must be followed by a space }
| subterm(N-1) op(N,xfx) subterm(N-1)
| subterm(N-1) op(N,xfy) subterm(N)
| subterm(N) op(N,yfx) subterm(N-1)
| subterm(N-1) op(N,xf)
| subterm(N) op(N,yf)

term(1000) --> subterm(999) , subterm(1000)

term(0) --> functor ( arguments )
{ provided there is no space between
the functor and the '(' }
| ( subterm(1200) )
| { subterm(1200) }
| list
| string
| constant
| variable

op(N,T) --> functor
{ where functor has been declared as an
operator of type T and precedence N }

arguments --> subterm(999)
| subterm(999) , arguments

list --> '[]'
| [ listexpr ]

listexpr --> subterm(999)
| subterm(999) , listexpr
| subterm(999) | subterm(999)
| '..' subterm(999)

constant --> atom | integer

atom --> name
{ where name is not a prefix operator }

integer --> number
| '-' number

functor --> name

http://centria.di.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf

[Jan Burse]

Jan Burse schrieb:

> Also it is not specially tied to WAM. You can replace
> helper functions such as create_compound by your own
> functions, that generate the parsed term in your own
> data structure. Whatever this might be.

BTW: Unparsing is a little bit more trickyer than parsing.
Especially when you want to be ISO compliant.

But I guess GNU Prolog has also somewhere an unparsing
routine.

Bye

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mf6d6h$1kv$1...@news.albasani.net...

> Julio Di Egidio schrieb:
>> I would just not want to couple the parser with the implementation, nor
>> I would nowadays implement a Prolog engine based on the WAM. So, it is
>> a pity if that parser outputs a WAM-specific syntax tree (and indeed it
>> appears it does): OTOH, I'd guess that parser was itself generated from
>> a grammar...?
>
> Not really.
>
> Its just a hand-written deterministic recursive decend
> parser. It might be derived from a specification, but
> it is not an executable specification, again if there
> was any spacification, it was used as a sweat specification.
>
> Also it is not specially tied to WAM. You can replace
> helper functions such as create_compound by your own
> functions, that generate the parsed term in your own
> data structure. Whatever this might be.

Hmm, OK, I'll look into it.

> P.S.: BTW the specification itself isn't that
> troublesome, you find it for example in the DEC10
> Prolog manual, it is really simple:
>
> I.7.3. Syntax of Terms as Tokens

<snip>
>
> http://centria.di.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf

It is not that simple, I said fully conformant parser: but years have passed
since I have investigated these issues, and all my research is anyway gone
in a major disk crash, together with a copy indeed of the standard... so I
cannot be more precise than that. Just for sure I am not going to buy the
standard again, as it turns out that indeed nobody cares so that the mistake
was mine to begin with:

http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a

Julio

[Julio Di Egidio]

"Julio Di Egidio" <ju...@diegidio.name> wrote in message
news:mf6hpr$t2k$1...@dont-email.me...

> Just for sure I am not going to buy the standard again, as it turns out
> that indeed nobody cares so that the mistake was mine to begin with:

I was kidding, of course: not having an industrial standard may not be a big
deal for the scientist, it is a showstopper for the engineer.

> http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a

Julio

[Jan Burse]

Julio Di Egidio schrieb:

>
> It is not that simple, I said fully conformant parser:

> [.. Snip ..]

> indeed nobody cares so that the mistake was mine to begin with:

Yeah I know, professional software engineers hide
behind all kind of arguments to avoid work. For
example when I wanted to build a JSP application,
somebody told me that JSP is an anti-pattern.

Same with the urban myth about Prolog parsing.
Common, get real. What is the big deal with
Prolog parsing? You even don't need the ISO standard
for it, the ISO standard did copy Prolog syntax
from somewhere else. So what?

BTW: The GNU Parser is considered by Ulrich Neumerkel,
one of the syntax Gurus for ISO Prolog, probably a
co-creator of the urban myth, as one of the few
fully conformant parsers. See for example here.
It says:


2. GNU Prolog 1.4.4 (git version). Not known
to misread any valid Prolog text. Some differences
in arithmetics. Otherwise Cor.1, Cor.2.

http://stackoverflow.com/questions/20119749/is-there-an-iso-prolog-reference-implementation/20123925#20123925

For example the GNU Parser parses "- /* abc */ 123"
as -123. Whereas my Parser for Jekejeke Prolog and
SWI-Prolog parses it as -(123).

The test cases established by Ulrich Neumerkel
are public, you can use them to verify your own
implementation:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mf6qon$r10$1...@news.albasani.net...

> Julio Di Egidio schrieb:
>>
>> It is not that simple, I said fully conformant parser:
> > [.. Snip ..]
> > indeed nobody cares so that the mistake was mine to begin with:
>
> Yeah I know, professional software engineers hide
> behind all kind of arguments to avoid work.

That is the opposite of what I said as well as the opposite of the truth,
bonzo. But there is of course nothing under the sun more underrated than
software engineering nowadays, isn't there, as pretty much nobody
understands a flying fuck about it anyways, CS adepts in primis. (Not
primarily a fault of the students, of course.) Funny thing is you respect a
civil engineer as the bridge otherwise could fall, but you think building
software is easy... to the contrary, note that SE is the most complex
engineering that there is, and you are just and apparently clueless about
it.

> For
> example when I wanted to build a JSP application,
> somebody told me that JSP is an anti-pattern.

And that is correct: you know, one thing is you build an app, another is to
run a software house and consistently build real systems for real needs at
decent levels of quality and cost. Indeed, but just for the chronicle, at
the level of enterprise patterns, architectures and even the language
paradigms, the so called "Java community" has done more damage than any
other group of interest re proper software engineering and programming.

> Same with the urban myth about Prolog parsing.

The (anti-)myths and the naive understanding are all yours.

> Common, get real. What is the big deal with
> Prolog parsing? You even don't need the ISO standard
> for it, the ISO standard did copy Prolog syntax
> from somewhere else. So what?

Industrial-level standardisation: look it up, it is a key enabling factor
for industrial/technological societies.

> BTW: The GNU Parser is considered by Ulrich Neumerkel,
> one of the syntax Gurus for ISO Prolog, probably a
> co-creator of the urban myth, as one of the few
> fully conformant parsers.

<snip>

If he says so, it is very good news: but if the parser is too coupled with
WAM, either it is still bad news or I am missing something.

Whatever, you are an incorrigible knowitall, and there is no point in
explaining anything to you...

Julio

[Jan Burse]

Julio Di Egidio schrieb:

>
> If he says so, it is very good news: but if the parser is too coupled
> with WAM, either it is still bad news or I am missing something.

There is not much coupling with the WAM. Just replace for example:

Create_Structure(int func, int arity, WamWord *arg)
{
}

By whatever you want. Also WamWord by whatever you want.

The structure of the parser is explained in the comment of
file. The comment says:

PARSE_TERM

Recursively parses a term whose precedence is <=cur_prec
and returns a WamWord associated to the term. If a syntax
error is encountered the parser returns NOT_A_WAM_WORD and
update syntax error information (see
Set_Last_Syntax_Error_Info() in error_supp.c).

The flag comma_is_punct specifies if an eventual ','
following the term must be considered as a punctuation
(separator of args of compound term or of a list) or
as an atom. The value COMMA_ANY is used when this
flag is not relevant (only for comprehensivity).

Since the Pl_Scan_Token() only consumes necessary
characters, the function Pl_Stream_Peekc() returns
the character immediately after the pl_token.

This feature is used to detect negative numbers and open
bracket thus the next call to Pl_Scan_Token() will return
TOKEN_IMMEDIAT_OPEN). We use Pl_Scan_Peek_Char() instead
of Pl_Stream_Peekc() only to deal with character
conversion.

http://sourceforge.net/p/gprolog/code/ci/457f7b447c2b9e90a09956ff15fd277d269b1d98/tree/src/BipsPl/parse_supp.c

But you are right, the above parser might not be sufficient for
ones purpose:

- I am not sure whether it supports Unicode (
SWI-Prolog and Jekejeke meanwhile do, although
in different ways)

- There are more dependencies to the WAM so that
a porting might not be a one day job

- The implementation lacks the use of the Spring
Framework (replace by the framework that applies
to your shop), since my employer has recently
hired an expert(*) on the Spring Framework, it should
make use of this Framework.

Bye

(*)
The guy who is responsible for the walkways along the bridge,
see also Coding Sucks: Why a Job in Programming Is Absolute Hell
https://www.youtube.com/watch?v=MticYPfFRp8

[Jan Burse]

Jan Burse schrieb:

>
> - I am not sure whether it supports Unicode (
> SWI-Prolog and Jekejeke meanwhile do, although
> in different ways)

GNU Prolog does not support a large character range,
at least not on Windows:

GNU Prolog 1.4.4:
?- char_code(X,1000).
uncaught exception:
error(representation_error(character_code),char_code/2)

SWI-Prolog 7.1.32:
?- char_code(X,1000).
X = 'Ϩ'.

Jekejeke Prolog 1.0.5:
?- char_code(X,1000).
X = 'Ϩ'

[Dhu on Gate]

It's a limitation of design, not platform:

GNU Prolog 1.4.5 (64 bits)
Compiled Dec 4 2014, 07:57:57 with gcc
By Daniel Diaz
Copyright (C) 1999-2014 Daniel Diaz
| ?- X is 281462092005375*4096, integer(X).

X = 1152868728854016000

yes

| ?- char_code(X,1000).
uncaught exception: error(representation_error(character_code),char_code/2)

| ?- char_code(X,256).
uncaught exception: error(representation_error(character_code),char_code/2)
| ?- char_code(X,255).

X = '\xff\'

yes
| ?-

Dhu


--
Ne obliviscaris, vix ea nostra voco.

[Jan Burse]

Dhu on Gate schrieb:

> It's a limitation of design, not platform:

The platform might nevertheless rain in
ones parade. I am not sure what character
set is used for the range 128-255 in GNU
Prolog? Same on Linux and Windows?

Here is also a funny platform dependency:

?- X is 2.2250738585072011e-308 - 2.2250738585072012e-308,
X==0.

Gives different results on the two platforms
Linux and Windows for GNU Prolog 1.4.4. At
least for the out of the box yum install
respective .exe from the web site.

I don't say this is bad. Just saying such
things do exist. Sometimes by design.

Bye

[Ulrich Neumerkel]

"Julio Di Egidio" <ju...@diegidio.name> writes:
>It is not that simple, I said fully conformant parser: but years have passed
>since I have investigated these issues, and all my research is anyway gone
>in a major disk crash, together with a copy indeed of the standard... so I
>cannot be more precise than that. Just for sure I am not going to buy the
>standard again, as it turns out that indeed nobody cares so that the mistake
>was mine to begin with:
>
>http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a

Please, would you mind to read it? This was written three and a half years
after the publication of the standard in 1995 while ignoring IF, Minerva,
Prolog IV, and GNU.

In the meantime almost all of the issues mentioned there have been addressed
by many of the mentioned systems. SICStus is fully conforming &ct. So
please consider the part "SICStus Prolog versus ISO Prolog" nixed.

What remains are general remarks on policies and the like.

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Same with the urban myth about Prolog parsing.
>Common, get real. What is the big deal with
>Prolog parsing? You even don't need the ISO standard
>for it, the ISO standard did copy Prolog syntax
>from somewhere else. So what?

A lot of tiny details have been resolved with the ISO standard.
So your statement that "the ISO standard did copy Prolog syntax
from somwhere else" is incorrect.

>BTW: The GNU Parser is considered by Ulrich Neumerkel,
>one of the syntax Gurus for ISO Prolog, probably a
>co-creator of the urban myth, as one of the few
>fully conformant parsers. See for example here.
>It says:
>
>
> 2. GNU Prolog 1.4.4 (git version). Not known
> to misread any valid Prolog text. Some differences
> in arithmetics. Otherwise Cor.1, Cor.2.
>
> http://stackoverflow.com/questions/20119749/is-there-an-iso-prolog-reference-implementation/20123925#20123925
>
>For example the GNU Parser parses "- /* abc */ 123"
>as -123. Whereas my Parser for Jekejeke Prolog and
>SWI-Prolog parses it as -(123).

See http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#59

SWI is non-conforming here, and IF, YAP, B, GNU, SICStus, Minerva,
XSB, Ciao and Prolog IV all conform.

[Jan Burse]

Jan Burse schrieb:

> The platform might nevertheless rain in
> ones parade. I am not sure what character
> set is used for the range 128-255 in GNU
> Prolog? Same on Linux and Windows?

Yes, indeed, even char_code/2 is different
on different platforms:

On Linux:

GNU Prolog 1.4.4 (64 bits)
Compiled Aug 3 2013, 20:06:22 with gcc
By Daniel Diaz
Copyright (C) 1999-2013 Daniel Diaz

| ?- char_code(X,255).

X = '\xff\'

On Windows:

GNU Prolog 1.4.4 (64 bits)
Compiled Apr 23 2013, 16:05:07 with cl
By Daniel Diaz
Copyright (C) 1999-2013 Daniel Diaz
| ?- char_code(X,255).

X = ÿ

But I guess its not really the char_code/2
predicate that delivers different results,
rather the unparser, which propably accesses
some C routine to decide printability or
a character code. And this C routine might
be differently configured on Windows and Linux.

Bye

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:
> Seehttp://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#59

>
> SWI is non-conforming here, and IF, YAP, B, GNU, SICStus, Minerva,
> XSB, Ciao and Prolog IV all conform.

I guess minerva does not exist anymore. At least the
link in your assessment http://www.ifcomputer.com/MINERVA/
gives a 404 error.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> A lot of tiny details have been resolved with the ISO standard.
> So your statement that "the ISO standard did copy Prolog syntax
> from somwhere else" is incorrect.

An altered copy, is also a copy.

[Julio Di Egidio]

"Ulrich Neumerkel" <ulr...@mips.complang.tuwien.ac.at> wrote in message
news:2015Mar3...@mips.complang.tuwien.ac.at...

> "Julio Di Egidio" <ju...@diegidio.name> writes:
>>It is not that simple, I said fully conformant parser: but years have
>>passed
>>since I have investigated these issues, and all my research is anyway gone
>>in a major disk crash, together with a copy indeed of the standard... so I
>>cannot be more precise than that. Just for sure I am not going to buy the
>>standard again, as it turns out that indeed nobody cares so that the
>>mistake
>>was mine to begin with:
>>
>>http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a
>
> Please, would you mind to read it? This was written three and a half years
> after the publication of the standard in 1995 while ignoring IF, Minerva,
> Prolog IV, and GNU.

I have read it: I have chosen that link just to testify that it is a long
story indeed. That there are at least a couple of fundamental problems with
the standard (overcomplexity of the grammar and it is not fully inconsistent
anyway) is a *fact*.

> In the meantime almost all of the issues mentioned there have been
> addressed
> by many of the mentioned systems. SICStus is fully conforming &ct. So
> please consider the part "SICStus Prolog versus ISO Prolog" nixed.
>
> What remains are general remarks on policies and the like.

What remains is that you, the real (and I mean it) living representant of
the Prolog standard, fix my system as well, so that I can be in the
competition, too. -- No, I am kidding, I'll simply hijack GNU's one, after
all it passes unit tests...

Julio

[Julio Di Egidio]

"Julio Di Egidio" <ju...@diegidio.name> wrote in message

news:mfch7f$8vv$1...@dont-email.me...

> it is not fully inconsistent

it is not fully consistent

Julio

[Ulrich Neumerkel]

"Julio Di Egidio" <ju...@diegidio.name> writes:
>I have read it: I have chosen that link just to testify that it is a long
>story indeed. That there are at least a couple of fundamental problems with
>the standard (overcomplexity of the grammar and it is not fully inconsistent
>anyway) is a *fact*.

Overcomplexity is quite a judgemental property. But you say that
the grammar is not fully consistent. Could you please elaborate on
this, as you say "*fact*"?

[Jan Burse]

Julio Di Egidio schrieb:

> I have read it: I have chosen that link just to testify that it is a
> long story indeed. That there are at least a couple of fundamental
> problems with the standard (overcomplexity of the grammar and it is not
> fully inconsistent anyway) is a *fact*.

Hi,

On the linked abstract you gave Roberto Bagnara himself
summarizes his observations on the ISO standard
as follows:

"- Does the logic programming community want to have a standard?
- If so, is ISO Prolog the "right" standard?
- If ISO Prolog is not the "right" standard, why?"
(Roberto Bagnara, at the end of
http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a)

I don't read complexity and consistency issues out of this.
This is really an urban myth my dear.

Interestingly in the linked abstract Roberto Bagnara gives
his own answer to the above questions, which are basically
pro ISO standard:

"It may well be the case that ISO Prolog is not the best
possible standard: no standard I know enjoys this property.
Indeed, there are several things that I do not like in
ISO Prolog. But I believe that it is a reasonable compromise.
Moreover, I do believe that following ISO Prolog is much,
much better than following no standard at all."
(Roberto Bagnara, in the last but one paragraph of
http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a)

Bye

[Jan Burse]

Jan Burse schrieb:

> On the linked abstract you gave Roberto Bagnara himself
> summarizes his observations on the ISO standard
> as follows:

his main questions

[Jan Burse]

If you compare the below with the ISO standard,
you will find that the ISO standard basically
does the same.

But where the thing fits in one page here, the
ISO standard does it on 25 pages or so.

So the ISO standard is quite verbose, which
isn't bad.

Jan Burse schrieb:

[Julio Di Egidio]

"Ulrich Neumerkel" <ulr...@mips.complang.tuwien.ac.at> wrote in message
news:2015Mar3...@mips.complang.tuwien.ac.at...

> "Julio Di Egidio" <ju...@diegidio.name> writes:
>
>>I have read it: I have chosen that link just to testify that it is a long
>>story indeed. That there are at least a couple of fundamental problems
>>with
>>the standard (overcomplexity of the grammar and it is not fully
>>inconsistent
>>anyway) is a *fact*.
> Overcomplexity is quite a judgemental property.

Nah, that Prolog's grammar is at the top of grammar complexity is a *fact*.

> But you say that
> the grammar is not fully consistent. Could you please elaborate on
> this, as you say "*fact*"?

You say clearly that I am speaking nonsense, and I will take the time prove
you wrong.

Julio

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mfdim7$vc9$1...@news.albasani.net...

> Julio Di Egidio schrieb:
>> I have read it: I have chosen that link just to testify that it is a
>> long story indeed. That there are at least a couple of fundamental
>> problems with the standard (overcomplexity of the grammar and it is not
>> fully inconsistent anyway) is a *fact*.
>
> Hi,
>
> On the linked abstract you gave Roberto Bagnara himself
> summarizes his observations on the ISO standard
> as follows:
>
> "- Does the logic programming community want to have a standard?
> - If so, is ISO Prolog the "right" standard?
> - If ISO Prolog is not the "right" standard, why?"
> (Roberto Bagnara, at the end of
> http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a)
>
> I don't read complexity and consistency issues out of this.
> This is really an urban myth my dear.

You are just a moron who cannot keep distinct things distinct.

Julio

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mfdjhn$pt$1...@news.albasani.net...

> If you compare the below with the ISO standard,
> you will find that the ISO standard basically
> does the same.

Down here where real software is produced, you can stick that "basically" up
your ass.

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> Nah, that Prolog's grammar is at the top of grammar complexity is a *fact*.

The Haskell Syntax looks more complex to me than the Prolog Syntax:

9.5 Context-Free Syntax
https://www.haskell.org/onlinereport/syntax-iso.html

Usally Prolog Syntax is considered simple.

[Ulrich Neumerkel]

"Julio Di Egidio" <ju...@diegidio.name> writes:
>> But you say that
>> the grammar is not fully consistent. Could you please elaborate on
>> this, as you say "*fact*"?
>
>You say clearly that I am speaking nonsense, and I will take the time prove
>you wrong.

Why don't you simply produce the evidence for your claim? You
talked about facts, not future projects.

[Julio Di Egidio]

Because while I am always open to learning something new, I have no more time to waste than you have. So you speak straight, in order to show that you are a honest interlocutor, then I will certainly take the time, cold I deny anything to you anyway?

Julio

[Dhu on Gate]

On Mon, 30 Mar 2015 17:08:43 +0000, Dhu on Gate wrote:

> On Sat, 28 Mar 2015 21:43:31 +0100, Jan Burse wrote:
>
>> Jan Burse schrieb:
>>>
>>> - I am not sure whether it supports Unicode (
>>> SWI-Prolog and Jekejeke meanwhile do, although
>>> in different ways)
>>
>> GNU Prolog does not support a large character range,
>> at least not on Windows:
>>
>> GNU Prolog 1.4.4:
>> ?- char_code(X,1000).
>> uncaught exception:
>> error(representation_error(character_code),char_code/2)
>>
>> SWI-Prolog 7.1.32:
>> ?- char_code(X,1000).
>> X = 'Ϩ'.
>>
>> Jekejeke Prolog 1.0.5:
>> ?- char_code(X,1000).
>> X = 'Ϩ'
>
> It's a limitation of design, not platform:
>

or rather by design.

[rupert...@googlemail.com]

On Saturday, March 28, 2015 at 7:26:46 PM UTC, Julio Di Egidio wrote:
> the so called "Java community" has done more damage than any
> other group of interest re proper software engineering and programming.

Java allows separation of interfaces and implementation, which is good for decoupling as per Parna's rules. Its also the only widely used production quality language with checked exceptions (I hate surprises). I think these things together make it a pretty good choice for well engineered software. At least, I thought so when I had to carry the on-call phone and potentially be woken up in the middle of the night if my code failed; I never got the call.

Its popularity that has resulted in the mass of bad Java software out there, and the low standards we expect from developers. If Prolog was the most popular programming language in the world, would there not be just as many clueless people using it and churning out the same kind of crap? It would probably be worse, Prolog is harder to read than Java.

[Julio Di Egidio]

Mate, I've been doing my job for 35 years, not to mention that I come from 2 generations of family tradition in engineering and technology: so you know what, just go fuck yourself and rather learn to use question marks.

Sincerely,

Julio

[Dhu on Gate]

IO has always been a weak area for prolog...
logic seems insufficient, if necessary to practical things ;-)

[Julio Di Egidio]

On Thursday, April 2, 2015 at 10:32:33 PM UTC+1, Dhu on Gate wrote:
> On Mon, 30 Mar 2015 23:01:30 +0200, Jan Burse wrote:

<snip>

> > a character code. And this C routine might
> > be differently configured on Windows and Linux.
>

> IO has always been a weak area for prolog...
> logic seems insufficient, if necessary to practical things ;-)

Total bullshit, and I mean it: there are only two things you cannot come to term with by logic, and these are the liar and the plain idiot; or both.

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> Mate, I've been doing my job for 35 years, not to
> mention that I come from 2 generations of family
> tradition in engineering and technology: so you
> know what, just go fuck yourself and rather learn
> to use question marks.

In the 80's I tried to show a Prolog interpreter
to a physics professor. I used the following
example program:

fac(0, 1).
fac(N, Y) :-
N > 0,
M is N-1,
fac(M, X),
Y is N*X.

Unfortunately I couldn't get to the point of
explaining the program. The poor little fellow
got angry because I was using the predicate
name "fac".

Ok, from now on I am always trying to use the
predicate name "factorial", but "fac" is much
shorter and saves typing.

Lessons learnt: There are people that are
intimitaded by words such as "fuck yourself",
"ass up", etc.. But even more robust people,
that are not initimitaded, might send you to
the kill file of the newsreader when they see
these words.

The effect is in both cases the same, you get
ignored.

Bye

[Julio Di Egidio]

I don't give a fuck about you and your fallacious bullshit, you are apparently just a moron and I mean it, so *you* are in my *shit* file, idiotic moron with half brain and no balls...

LOL, and now really *plock*.

Julio

[Julio Di Egidio]

On Friday, April 3, 2015 at 3:55:47 PM UTC+1, Jan Burse wrote:

> Julio Di Egidio schrieb:
> > Mate, I've been doing my job for 35 years, not to
> > mention that I come from 2 generations of family
> > tradition in engineering and technology: so you
> > know what, just go fuck yourself and rather learn
> > to use question marks.
>
> In the 80's I tried to show a Prolog interpreter
> to a physics professor. I used the following
> example program:

For the chronicle, it is really the morons like you the main cause of the software and not only crisis: if it were not for the morons like you, the speculators of all kinds would not have that easy a life. But you are (of course not a speculator, I can see you are too dim-witted for that) such a moron, you and the majority of those speaking their abusive nonsense on these and all matters... dim-witted abusive moron...

So, thanks you so much, for the shithole you and co. make us all leave in: I will personally feel "in debt" with you for life, and I mean... And now, again, just fuck off, piece of shit. EOD.

Julio

[Julio Di Egidio]

Errata:

plock = plonk
and I mean... = and I mean it...
fuck you for good = n'gulammammeteforever
this is the best world *you* could conceive = n'gulammameteforeverandever

Julio

[Julio Di Egidio]

On Friday, April 3, 2015 at 3:55:47 PM UTC+1, Jan Burse wrote:

> Bye

All that said, I am just going to kill file you for good.

Julio

[Julio Di Egidio]

You are just another piece of shit: I have never seen you *in years* around here do anything at all but cover your ass and defend the status quo, so, while pointing out that we couldn't care less about your Prolog, your speculations, and your fake standards, as what we are interested is actually the logical paradigm per se, you do now get into my shit list (kill file), too.

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> You are just another piece of shit: I have never seen you*in
> years* around here do anything at all but cover your ass and
> defend the status quo, so, while pointing out that we couldn't
> care less about your Prolog, your speculations, and your fake
> standards, as what we are interested is actually the logical
> paradigm per se, you do now get into my shit list (kill file), too.

I don't see any use here in bashing Ulrich. The original beginning
of this thread was very positive, showing a recent real world
use of Prolog, namely in the specification of newer JVMs.

Then the discussion turned into the question whether Prolog has
a difficult syntax or not. Ulrich showed genuine interest in
this question, so do I. Meanwhile I have found another example
of another syntax I consider more difficult than Prolog.

I was giving the example of Haskell syntax. But there is another
syntax which I also judge more difficult than Prolog. This
is the syntax of SQL. Besides EXIST statements in the WHERE clause,
and SELECT statements in SELECT columns, it has also such things
as multiary conditions, i.e. the BETWEEN etc..

But I guess the discussion has turned into I dunno what, so
we will never know why Prolog is considered a diffcult syntax.
Is it difficult because its table driven, i.e. the syntax
operator table? I don't think that this makes the language
especially difficult.

The GNU source code shows that a fixed routine flow
parses prefix, infix and postfix operators, of course depending
on the actual operator table definition. But the routine flow
looks still simple and elegant to me. I don't know whether
other languages have such simple and elegenat parsers.

Anyway, we will never know, what makes Prolog syntax difficult...

Bye

[Dhu on Gate]

On Thu, 02 Apr 2015 16:03:47 -0700, Julio Di Egidio wrote:

> On Thursday, April 2, 2015 at 10:32:33 PM UTC+1, Dhu on Gate wrote:
>> On Mon, 30 Mar 2015 23:01:30 +0200, Jan Burse wrote:
> <snip>
>> > a character code. And this C routine might
>> > be differently configured on Windows and Linux.
>>
>> IO has always been a weak area for prolog...
>> logic seems insufficient, if necessary to practical things ;-)
>
> Total bullshit, and I mean it: there are only two things you cannot come to term with by logic,

Logic ++ domain knowledge. Levers gotta have a fulcrum.

Dhu

> and these are the liar and the plain idiot; or both.
>
> Julio

[Dhu on Gate]

On Thu, 02 Apr 2015 16:03:47 -0700, Julio Di Egidio wrote:

On re-read I'm not sure you're clearing the difference between necessity and sufficiency.

[Julio Di Egidio]

On Friday, April 3, 2015 at 10:29:08 PM UTC+1, Dhu on Gate wrote:

> On re-read I'm not sure you're clearing the difference between necessity and sufficiency.

I don't know you, nor you have been particularly stupid so far, so I'll refrain from using the same tone with you as with the usual swine, but please do not abuse of my openness and magnanimity.

Cheers,

Julio

[Dhu on Gate]

There are usually 3 sets of domain knowledge necessary for computer programming.
There is the actual domain under consideration, the domain of the language
(syntax, semantics, etc.) and the domain of the execution environment, an
understanding of which is requisite to any useable mmi. Then you need a
lemma(or proposition) of some kind to subject to some constructive proof:
the rest of the program is side effect of this (usually trivial) undertaking.

A similar, related conceipt, is that of communication. WS describes this
(argal, she did not kill herself) such that A proposes L0 to B. B validates
this by proposing logically consistent mods to L0 in the local context b and
returns modified L0b to A. A can then determine that the mod to L0b was
both a logical extentions of L0, but with unpredicted local domain knowledge,
constituting a communication between A and B.

This mechanism allows for A to prove that it's local context includes B,
validating the existence of both A and B within the local context of a....

[Dhu on Gate]

On Mon, 30 Mar 2015 20:45:35 +0000, Ulrich Neumerkel wrote:

>
> See
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#59
>
> SWI is non-conforming here, and IF, YAP, B, GNU, SICStus, Minerva,
> XSB, Ciao and Prolog IV all conform.

Just had a look at this, and did a spotcheck:

SWI:| ?- X is 10.0** -323, writeq(X).
9.8813129168249309e-324

X = 9.8813129168249309e-324

yes

?- X is 10.0** -323, writeq(X).
1.0e-323
X = 1.0e-323.
?- write_canonical(_+_).
+(_,_)
true.

?- write_canonical(B+B).
+(A,A)
true.

?- writeq('a\b'). % "a\\\n b"
'a\b'
true.

GNU:
| ?- write_canonical(_+_).
+(_279,_280)

yes
| ?- write_canonical(B+B).
+(_279,_279)

yes
| ?- writeq('a\b'). % "a\\\n b"
'a\b'

yes

And notice that this does not conform to the table's claim. Then I notice
that the table has GNU 1.4.5 (latest and greatest) and SWI 6.3.18-3

GNU Prolog 1.4.5 (64 bits)

Compiled Dec 4 2014, 07:57:57 with gcc
By Daniel Diaz
Copyright (C) 1999-2014 Daniel Diaz

but on my box
[dhu@gate:~] $ swipl
Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 6.6.4)
Copyright (c) 1990-2013 University of Amsterdam, VU Amsterdam
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
Please visit http://www.swi-prolog.org for details.

More useful to those of us using Prolog in the real world would
be variance lists comparing the actual behaviour of these languages
where they vary FROM EACH OTHER, not from some abstract language
definition that has never been completely implemented.

Not saying there's no place for this, as guys like J.B. have to
concern themselves with stuff like this but...

[Dhu on Gate]

On Fri, 03 Apr 2015 16:55:45 +0200, Jan Burse wrote:

> Julio Di Egidio schrieb:
>> Mate, I've been doing my job for 35 years, not to
>> mention that I come from 2 generations of family
> > tradition in engineering and technology: so you
> > know what, just go fuck yourself and rather learn
> > to use question marks.
>
> In the 80's I tried to show a Prolog interpreter
> to a physics professor. I used the following
> example program:
>
> fac(0, 1).
> fac(N, Y) :-
> N > 0,
> M is N-1,
> fac(M, X),
> Y is N*X.
>
> Unfortunately I couldn't get to the point of
> explaining the program. The poor little fellow
> got angry because I was using the predicate
> name "fac".
>

I generally find that using functors like "fuktorial"
gets the point across quicker ;-)

> Ok, from now on I am always trying to use the
> predicate name "factorial", but "fac" is much
> shorter and saves typing.
>
> Lessons learnt: There are people that are
> intimitaded by words such as "fuck yourself",
> "ass up", etc.. But even more robust people,
> that are not initimitaded, might send you to
> the kill file of the newsreader when they see
> these words.

I haven't yet figured out if Julio is one of our standard
Turing Trolls here or just another smart kid who's
only seen one lightbulb go on...

Dhu

>
> The effect is in both cases the same, you get
> ignored.
>
> Bye

[Dhu on Gate]

On Thu, 26 Mar 2015 10:51:48 +0100, Jan Burse wrote:

> Jan Burse schrieb:

>> So I really take it, that Prolog was used as
>> a specification, but not as an executable specification,
>> but simply as a sweat specification, to manually
>> implement something.
>
> It seems that there was a transition from type inference
> to type checking. I guess for performance reasons.

Hmm. Couldn't get it to run, meself. I saw this some time
back an' tho't "Wooo, away around that ARM mess..."

So iff there's GNU Prolog running now on Java (as opposed to c)
I'd reallly like to hear more about it.

Dhu

[Dhu on Gate]

I haven't noticed JB losing it too often, however you appear to want
to elevate this discourse from the merely logical to the theological.

And in that area you are like to lose, if only to number2.

[Julio Di Egidio]

"Dhu on Gate" <camp...@neotext.ca> wrote in message
news:Wv6Uw.181274$sB1....@fx22.iad...
<snip>

> I haven't noticed JB losing it too often,

Maybe there was just nothing to lose?

> however you appear to want
> to elevate this discourse from the merely logical to the theological.

Not at all, if I have an aspiration, that is to universality, certainly not
to "theology". In fact, the so revered opposition science/theology is
actually yet another sign of how superstitious but in fact rotten and
intrinsically false to itself is the global culture.

> And in that area you are like to lose, if only to number2.

I'm having tea with number2... whichever your point was.

Julio

[Jan Burse]

Dhu on Gate schrieb:

> So iff there's GNU Prolog running now on Java (as opposed to c)
> I'd reallly like to hear more about it.

I didn't imply that GNU Prolog was used anywhere in
the JVM, either the old one with type inference or
the new one with type checking.

My hypothesis is that Prolog (not GNU Prolog) was
used as a specification. Specification means:

Lets keep it simple, every artefact
produced as a document, on the back of
an envelope or simply kept in mind, before
implementation, i.e. the real code writing.

So specification might include concept
of operation, requirements and architecture,
detailed designs, etc.. using methods
like use cases, feature maps, etc..

http://en.wikipedia.org/wiki/V-Model

So the specification is here:

http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf

And the implementatuon is here:

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Someone was hired by Oracle to do the realization (going
from specification to implementation). I was citing the
releavant parts of the jvms7 document naming such people:

Jan Burse wrote on 24.03.15 14:11:
> "Wei Tao, together with Frank Yellin, Tim Lindholm,
> and Gilad Bracha, implemented the Prolog verifier
> that formed the basis for the specification in both
> Java ME and Java SE. Wei then implemented the
> specification "for real" in the HotSpot JVM."

Jan Burse wrote on 26.03.15 10:36:
> "Later, Mingyao Yang improved the design and
> specification, and implemented the final version
> that shipped in the Reference Implementation of
> Java SE 6. The specification also benefited from
> the efforts of the JSR 202 Expert Group: Peter
> Burka, Alessandro Coglio, Sanghoon Jin, Christian
> Kemper, Larry Rau, Eva Rose, and Mark Stolz."

So these two paragraphs from jvms7 document mention
names like Wei Tao and Mingyao Yang. Whether these people
and other people engaged in the realization were using
some kind of Prolog compiler I don't know. And if they
were using a GNU based Prolog compiler, this is equally
in the dark for me.

It would be an interesting task for a journalist to
interview these people, and ask them how they did it
and publish a nice article somewhere. But I am not
aspiring to do that. My hypothesis is simple that
the specification was manually realized by manually
coding machine code, C code and Java code for the JVM,
mainly based on the following translation:

Jan Burse wrote on 25.03.15 14:19:
> I would say most likely Prolog predicate calls such as:
>
> xxx(obj,arg1,..,argn,res)
>
> Where turned into Java method calls by Wei and others:
>
> res = obj.xxx(arg1,..argn)

So there is a big misunderstanding, I never intended this
post as promoting any new GNU Prolog development. I was
only facinated by a probably large Prolog specification,
that was used in realizing a comparable large asssembler,
C and Java code.

Whether there are currently some GNU Prolog developments
related to Java is a totally different questions. And
whethere jvms7 influenced such GNU Prolog developments
is again a totally different question and I don't see
any indicatives in this direction the jvms7 document.

When I open the jvms7 document there is even no single
occurence of the word GNU in it. So I guess some posters
here have a certain obsession with GNU, i.e. the word
compiler triggers GNU, but it is quite possible that the
jvms project was not affected by GNU Prolog at all. Since
GNU wasn't mentioned in the jvms7 document at all.

But we sre in the same situtation here with the claim
that Prolog syntax is complex. My claim is that Prolog
was used in the jvms7 project as a sweat specification,
i.e. the realization was done manually. So both claims
have at the moment, neither a refutation nor a validation.

So lazyweb, go, go, produce some evidence.

Bye

[Jan Burse]

Jan Burse schrieb:

> So lazyweb, go, go, produce some evidence.

There is also no change here:
http://www.reddit.com/r/prolog/comments/301oeu/the_java_vm_specification_contains_a_lot_of_prolog/

Maybe should check back in 1-2 years. Saw the same
effect on SO, that some questions were only answered
years ago.

[Jan Burse]

Julio Di Egidio schrieb:

>
> Not at all, if I have an aspiration, that is to universality, certainly not
> to "theology".

I am aware that there is probably a trench war going on
between GNU and JVM. Since JVM also claims more and more
a certain universality:

http://www.infoq.com/presentations/Towards-a-Universal-VM

So what? Me as a end-user I should be happy that there is
a certain competition. But me as a end-user participating
in this war, isn't my thing.

Bye

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>Someone was hired by Oracle to do the realization (going
>from specification to implementation). I was citing the
>releavant parts of the jvms7 document naming such people:
>
>Jan Burse wrote on 24.03.15 14:11:
> > "Wei Tao, together with Frank Yellin, Tim Lindholm,
> > and Gilad Bracha, implemented the Prolog verifier
> > that formed the basis for the specification in both
> > Java ME and Java SE. Wei then implemented the
> > specification "for real" in the HotSpot JVM."

W.r.t "Someone". That someone was Tim Lindholm, once at Quintus,
then author of the JVM spec.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

>>> "Wei Tao, together with Frank Yellin, Tim Lindholm,
>>> > > and Gilad Bracha, implemented the Prolog verifier
>>> > > that formed the basis for the specification in both

>>> > > Java ME and Java SE. *****Wei then implemented the
>>> > > specification "for real" in the HotSpot JVM."*****

> W.r.t "Someone". That someone was Tim Lindholm, once at Quintus,
> then author of the JVM spec.

We are still in the dark. The above paragraph says only
where the specification comes from. And yes, it says that
the a Tom Lindholm was involved.

But it doesn't answer the question what was done with
the specification, how it went into the HotSpot JVM and
later versions of the Oracle JVM.

I am interested what they mean by the phrase "for real" in
the above paragraph (emphasis by *****). There is some
speculation that some kind of Prolog compiler was used. My
speculation is that it was manually realized.

Bye

[Jan Burse]

Jan Burse schrieb:

> But it doesn't answer the question what was done with
> the specification, how it went into the HotSpot JVM and
> later versions of the Oracle JVM.

You know there are many many JVMs implementations:
http://en.wikipedia.org/wiki/List_of_Java_virtual_machines

According to the JVMS spec, these implementations are
allowed to either implement type inference or type
checking or both (depending on byte code version). If
I understood it right, type checking would need to
realize the extra stack info and the Prolog spec.

What I see for the HotSpot is C++ code. And what I
see is a relatively large C++ routine:

void ClassVerifier::verify_method(methodHandle m, TRAPS) {
}

See here:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/share/vm/classfile/verifier.cpp

Doesn't look to me like generated from Prolog. Also
there are comments in it such as
// 4938384: relaxed constraint in JVMS 3nd edition.
Which looks like ordinary bug tracking to me.

Bye

[rupert...@googlemail.com]

Hey, I'm just engaging in the conversation, no need to tell me to go fuck myself.

I'd still say Java is a good language from an engineering standpoint and Prolog less so. Prolog is pretty much a failure of a language really, which is why there are just 5 grumpy old men on here that use it (myself included). I think Picat is worth a look: but no meta-programming support.

Rupert

[Jan Burse]

rupert...@googlemail.com schrieb:

> I'd still say Java is a good language from an
> engineering standpoint and Prolog less so.
> Prolog is pretty much a failure of a language
> really, which is why there are just 5 grumpy
> old men on here that use it (myself included).
>
> I think Picat is worth a look: but no meta-programming support.

Grumpy Cat approves: I was using something else
than Prolog once, it was horrible.

I recently observed that there is a certain
expectation about Prolog not to use it for
all the fancy logic stuff, but rather as a
scripting language.

Interestingly Prolog is a fine scripting
language as well. Here is a hack from
yesterday (doesn't work with Jekejeke 1.0.5,
only with upcoming release 1.0.6, still
fixing the system/file module a
little bit):

/**
* Prolog code to replace file names.
*
* Copyright 2015, XLOG Technologies GmbH, Switzerland
* Jekejeke Prolog 1.0.6 (a fast and small prolog interpreter)
*/

:- use_module(library(system/file)).

run(Dir) :-
directory_file(Dir, Name),
norm_atom(Name, Name2),
(Name \== Name2 ->
write((Name -> Name2)), nl,
make_path(Dir, Name, Path),
make_path(Dir, Name2, Path2),
rename_file(Path, Path2); true),
fail.
run(_).

% norm_atom(+Atom, -Atom)
norm_atom(Name, Name2) :-
atom_codes(Name, NameCodes),
norm_codes(NameCodes, NameCodes2),
atom_codes(Name2, NameCodes2).

% norm_codes(+Codes, -Codes)
norm_codes, "ae" --> "ä", !, norm_codes.
norm_codes, "ue" --> "ü", !, norm_codes.
norm_codes, "oe" --> "ö", !, norm_codes.
norm_codes, "Ae" --> "Ä", !, norm_codes.
norm_codes, "Ue" --> "Ü", !, norm_codes.
norm_codes, "Oe" --> "Ö", !, norm_codes.
norm_codes, "_" --> " ", !, norm_codes.
norm_codes, [C] --> [C], !, norm_codes.
norm_codes --> [].

But I am hesitant to promote Prolog as a scripting
language. It kind of sheds the wrong light on
Prolog. And it pushes Prolog in supporting a large
set of APIs, for all kind of OS access.

Bye

[Jan Burse]

Jan Burse schrieb:

> But I am hesitant to promote Prolog as a scripting
> language. It kind of sheds the wrong light on
> Prolog. And it pushes Prolog in supporting a large
> set of APIs, for all kind of OS access.

Even on Android devices there is a market for scripting.
I guess every shop has a boss, and this boss is hiring
a pour soul to do this and that via scripting. Why not
script from your tablet? (*)

"Scripts can be run interactively in a terminal, in the background, or
via Locale. Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and
shell are currently supported, and we're planning to add more. See the
SL4A Video Help playlist on YouTube for various demonstrations of SL4A's
features."
https://code.google.com/p/android-scripting/

(*)
But watch out scripting those missile launch facilities.

[Jan Burse]

Or dress the scripting tablets in steam punk suitcases:
https://www.youtube.com/watch?v=N1tGCDeOi2o

Jan Burse schrieb:

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mfr3pd$i7r$1...@news.albasani.net...

> Julio Di Egidio schrieb:
>>
>> Not at all, if I have an aspiration, that is to universality, certainly
>> not
>> to "theology".
>
> I am aware that there is probably a trench war going on
> between GNU and JVM.

First time I hear of it.

> Since JVM also claims more and more a certain universality:

That is not a surprise...

> http://www.infoq.com/presentations/Towards-a-Universal-VM
>
> So what? Me as a end-user I should be happy that there is
> a certain competition. But me as a end-user participating
> in this war, isn't my thing.

Which war are you talking about?

Julio

[Julio Di Egidio]

<rupert...@googlemail.com> wrote in message
news:6e6c8e70-9308-44f4...@googlegroups.com...
<snip>

> Hey, I'm just engaging in the conversation, no need to tell me to go fuck
> myself.

All right, peace... :)

> I'd still say Java is a good language from an engineering standpoin

But it is not, indeed primarily from an engineering stand point, but:
firstly, I am talking about the whole platform, not so much about the
language per se (which has shortcomings, but not dramatic); secondly, the
criticism is not simply about technical shortcomings of the platform (which
exist and, though sometimes dramatic, can still usually be worked around),
but much more so about the several (anti-)patterns and literally the
sabotaging to all relevant discipline that from that side have been
consistently promoted across the last couple of decades or so. -- To be
clear, when the real problem is to get a job done, we just do get it done,
and of course we do it even if Java is all we have at hand: the engineering
objection applies when that is supposed to happen consistently and at decent
levels of quality vs. cost.

> and Prolog less so. Prolog is pretty much a failure of a language really

I would strongly disagree: Prolog is an amazing language, just a *low-level*
one in an unfamiliar paradigm, which makes indeed the learning curve not
trivial, but, that said, not only Prolog is so powerful that we can and do
easily build higher-level languages of all kinds just on top of it,
including the more familiar ones, the *failure of Prolog* (IMO) is only and
all in the "technological infrastructure", which is not inexistent but
certainly far from industry-level strength. Essentially for the reasons I
had mentioned up-thread: an "infeasible" standard, and rather plain
counter-interest to an ubiquitous logic programming paradigm.

> which is why there are just 5 grumpy old men on here that use it (myself
> included). I think Picat is worth a look: but no meta-programming support.

I love Picat too, the language is much more expressive, so I wish it had
those features: yet, if I am not mistaken, Picat can still be easily
implemented on top a standard Prolog.

Julio

[Dhu on Gate]

On Sun, 05 Apr 2015 11:50:07 +0200, Jan Burse wrote:

> But we sre in the same situtation here with the claim
> that Prolog syntax is complex. My claim is that Prolog

From my experience complaints about the "complexity" of
Prolog sytax invariably come from people who don't grok
recursion.

[Julio Di Egidio]

"Dhu on Gate" <camp...@neotext.ca> wrote in message

news:WgVUw.155396$tF6....@fx11.iad...

> On Sun, 05 Apr 2015 11:50:07 +0200, Jan Burse wrote:
>
>> But we sre in the same situtation here with the claim
>> that Prolog syntax is complex. My claim is that Prolog
>
> From my experience complaints about the "complexity" of
> Prolog sytax invariably come from people who don't grok
> recursion.

Or from people who cannot even use Google, nor have seen the actual Prolog
standard even once.

Julio

[Jan Burse]

Hi,

Well this is a another kind of urban myth. This time
the claim is not that something is complex, i.e. the
Prolog syntax, but that something is simple, i.e. Picat
on top of "standard" Prolog.

Julio Di Egidio schrieb:

> I love Picat too, the language is much more expressive, so I wish it had
> those features: yet, if I am not mistaken, Picat can still be easily
> implemented on top a standard Prolog.

(Un-)fortunately Picat uses a kind of attribute variables,
called "Event-Driven Actors and Action Rules". These
attribute variables allow to provide constraint
solvers etc..

Although practically all bigger Prologs have some kind
of attribute variables, there is currently no standard
for attribute variables.

Strictly speaking attribute variables are an extension
beyond ISO Prolog. Prolog systems that provide constraint
solvers or similar subsystems based on attribute variables
cannot so easily be implemented on top of ISO Prolog.

Especially if one doesn't want some structures like
'meta(..)' (*) in the code and results, and wants some
opaque attribute variables.

Although attribute variables are an old invention, the
challenge for standardization is probably diversity among
existing implementations. But if I remember well, Ulrich
has already some paper about testing GC aspects of attribute
variables.

A standardization of attribute variables and trailed
updates would be a gas!

Bye

(*)
Interestingly Ulrich Neumerkel observes in
https://www.complang.tuwien.ac.at/ulrich/papers/PDF/meta90.pdf
that cyclic terms are needed to implement attribute
variables via 'meta(..)', i.e. if an attribute of an
attribute variable refers to the attribute variable itself.

For opaque attribute variables, such cycles might
not be obvious, only visible along the accessors
of the attribute variable. Posing its own GC problems
which I did not yet takle, in the case of
Jekejeke Prolog. :-(

[Jan Burse]

Julio Di Egidio schrieb:

> Which war are you talking about?

Most of academia, outside of some software engineering
circles that explicitly work on (J)VMs, hate Java. They
really really hate it.

They want there Linux Boxes with their C-Shell and their
source code to machine code compilers. They don't believe
in byte code and (J)VMs.

Happens all the time.

Bye

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mg1hct$nf7$1...@news.albasani.net...

Sure, and a total red herring was your drivel about what I said of Picat.

Man, you are a nut case, indeed a troll and as such I will be treating you.

In the meantime, have fun reinventing all wheels.

Julio

[Julio Di Egidio]

"Jan Burse" <janb...@fastmail.fm> wrote in message

news:mg1hmb$nf7$2...@news.albasani.net...

> Julio Di Egidio schrieb:
>> Which war are you talking about?
>
> Most of academia, outside of some software engineering
> circles that explicitly work on (J)VMs, hate Java. They
> really really hate it.

Your nonsense remains not even wrong.

> They want there Linux Boxes with their C-Shell and their
> source code to machine code compilers. They don't believe
> in byte code and (J)VMs.

You are simply a troll and I will tell you shit...

EOD.

Julio

[Jan Burse]

Julio Di Egidio schrieb:

> Or from people who cannot even use Google, nor have seen the actual
> Prolog standard even once.

90% what is found on the net is practically useless.
Here is an example, I made two exercises out of what
is missing:

Exercise 1: Rewrite the following left recursive,
one page Prolog syntax:

http://cseweb.ucsd.edu/classes/fa09/cse130/misc/prolog/prolog_tutorial.pdf
(Page 3)

Into a right recursive syntax. Why? Some compiler-
compilers have problems with left recursive syntax.

Exercise 2: Fix the above syntax to also cover what
the author of the tutorial admits to have left out
(my rephrasing):

"Prolog contains notational variations, such
as graphic atoms, some single character atoms,
infix, prefix and postfix notation, parenthesis,
comments not defined in this grammar. And it
allows a special syntax for lists and sets."

I guess this is rooted in the nature of tutorials, lectures
etc.., there is not enough room to do it in depth.

On the other hand the ISO standard does it right in my
opinion, but this shouldn't mean that I have changed my
mind, I still claim the Prolog syntax is simple.

I guess the ISO standard shouldn't be found on the
net, you must buy it. Putting it on the net is probably
a copy right breach. Its nevertheless leaking on the net.
Not sure whether it is some preprint:

http://wwwdh.cs.fau.de/IMMD8/Lectures/LOGIK/isoprolog.pdf


Bye

[Jan Burse]

Jan Burse schrieb:

> "Prolog contains notational variations, such
> as graphic atoms, some single character atoms,
> infix, prefix and postfix notation, parenthesis,
> comments not defined in this grammar. And it
> allows a special syntax for lists and sets."

And of course also extend the number and quoted atom
syntax to include hex, etc.. numbers (0xFF) and
escapes in quoted atoms ('abc\n\t\x1000\def'). And
the character code syntax (0'a).

Bye

[rupert...@googlemail.com]

On Tuesday, April 7, 2015 at 7:05:20 PM UTC+1, Julio Di Egidio wrote:
> > I'd still say Java is a good language from an engineering standpoin
>
> But it is not, indeed primarily from an engineering stand point, but:
> firstly, I am talking about the whole platform, not so much about the
> language per se (which has shortcomings, but not dramatic); secondly, the
> criticism is not simply about technical shortcomings of the platform (which
> exist and, though sometimes dramatic, can still usually be worked around),
> but much more so about the several (anti-)patterns and literally the
> sabotaging to all relevant discipline that from that side have been
> consistently promoted across the last couple of decades or so.

So the language is ok, its the people that use that make it bad? (<- That is a rhetorical question mark btw). That is something I would agree with. Some of the standards (JSRs) are ok. Its nice that Java has such a wide range of standardized libraries. Some are less good.

I blame Hibernate for inspiring a lot of bad Java, that was one of the first popular libraries that ditched checked exceptions and went runtime only. After that, everyone thought that was the clever way to do it, because they are lazy fools. Although Hibernate is not so bad really.

A year ago I worked 5 days over Christmas and new year, and turned 10K lines of Java into about 1K (and knowing me that was prbably 40% comments..., so call it 600). My program did the same thing as the 10K lines. That is typical of Java programmers, its like they want to get paid by the line of code or something. Me, I just want an easy life and keep it clean and simple.

Yes, I like Prolog too... But I never explored its module system. I think that is something the ISO standard didn't cover very well? But some systems have improved on it. Separating interface and implementation is what engineering in software needs.

[rupert...@googlemail.com]

On Tuesday, April 7, 2015 at 7:23:51 PM UTC+1, Dhu on Gate wrote:
> On Sun, 05 Apr 2015 11:50:07 +0200, Jan Burse wrote:
>
> > But we sre in the same situtation here with the claim
> > that Prolog syntax is complex. My claim is that Prolog
>
> From my experience complaints about the "complexity" of
> Prolog sytax invariably come from people who don't grok
> recursion.

I often find Prolog programs hard to read, but to be fair I spend much more time on Java, so it may just be inexperience. Prolog programs do often have variable names that are single letters. I started using proper names for my variables like Acummulator or SortedItems and so on, which can help.

What I like about Prolog, is that I can do much more with less code. If I look at some type checker I wrote in Prolog, it mostly just looks like the type checking rules written out, with the occasional helper predicate to do something not quite so straightforward. If I were to think how much Java code would be needed to achieve the equivalent, it would be a LOT more.

Its the tendency towards terseness that can make Prolog harder to read, in my opinion.

[rupert...@googlemail.com]

On Saturday, April 11, 2015 at 8:00:17 PM UTC+1, rupert...@googlemail.com wrote:
> I often find Prolog programs hard to read, but to be fair I spend
> much more time on Java, so it may just be inexperience. Prolog programs
> do often have variable names that are single letters. I started using
> proper names for my variables like Acummulator or SortedItems and so
> on, which can help.

Actually, what I do is write a predicate with single letter var names. Then I highlight it (in emacs), and replace text with better variable names. This saves me typing long var names first time around, but keeps the code more readable when I return to it later. An IntelliJ like editor for Prolog would be so helpful, with easy renaming, refactoring and auto-completion built in. When writing Java in ItelliJ I use helpful variable names, but very rarely have to type one out fully, just alt-space after the first few letters and it completes it for you.

[Julio Di Egidio]

On Saturday, April 11, 2015 at 7:50:32 PM UTC+1, rupert...@googlemail.com wrote:
> On Tuesday, April 7, 2015 at 7:05:20 PM UTC+1, Julio Di Egidio wrote:

<snip>

> So the language is ok, its the people that use that make it bad?

Can you read? The language is a piece of shit already, just not a showstopper, i.e. not the worst element of that puzzle. But you won't get it, this ain't stuff one can guess.

> I blame Hibernate for inspiring a lot of bad Java,

You just don't know really know what you are talking about, anyway yes, Hibernate is another piece of the same puzzle of sabotaging and shit, indeed already more important than the language per se.

Julio

[Jan Burse]

Hi,

Julio Bad Ass, we get, you are able to curse.

Bye

Julio Di Egidio schrieb:

[Jan Burse]

rupert...@googlemail.com schrieb:

Hi,

I guess you are aware, that you are adressing the human-parsability
of the language and not the machine-parsability. I think Julio Bad
Ass is claiming that the machine-parsability is hard, i.e. that
it is difficult to write a parser for Prolog.

What concerns human-parsability, there is already a nice document
giving advice:

Coding Guidelines for Prolog
Michael A. Covington et al.
last revised 17 May 2011
http://arxiv.org/abs/0911.2899

You will probably find some of the practice you have already
mentioned.

Bye

[Julio Di Egidio]

Suck my socks: only middle fingers for you.

Julio

[Jan Burse]

You're welcome Mr. Julio Bad Ass.

Julio Di Egidio schrieb:

[Julio Di Egidio]

Fuck you, Mr. Moron.

Julio

On Sunday, April 12, 2015 at 9:22:54 AM UTC+1, Jan Burse wrote:
> You're welcome Mr. Julio Bad Ass.
>
> Julio Di Egidio schrieb:
> > Suck my socks: only middle fingers for you.
> >

[Jan Burse]

LoL

Julio Di Egidio schrieb:

[rupert...@googlemail.com]

Java is a good engineering language for these reasons: It is well suited to working with Parnas' principles of modular design. One can group together similar functionality behind an interface, and one can design good interfaces to break a system into modules with minimal 'glue' between them. It is a safe language. It has checked exceptions, meaning that errors can be known about at compile time. It is fairly simple. Its good for working in teams, where mixed abilities are inevitable, because it is easy to pick up.

It takes a lot of experience to get the best out of it. An inexperienced team will make a huge mess.

It is not the best engineering language, but good enough that NASA run their Mars landers on it.

Yes, its not a very powerful language. Some people have called it an assembly language for the 21st century, although I doubt it will last that long.

The relational database/ORM situation is deplorable, I agree. It would be better suited to what it is most used for (server side API/ORM/transactional code), if it were something other than what it is. I think actually, something like a Prolog based on transaction logic, where there is no impedance mismatch between the language and the database would be better.

Quit being a whining baby Julio, and tell us what your vision of a better language is?

[Julio Di Egidio]

On Monday, April 13, 2015 at 12:17:15 PM UTC+1, rupert...@googlemail.com wrote:

> Quit being a whining baby Julio, and tell us what your vision of a better language is?

I have already told you and quite clearly that the language per se is the least of the problems. Your post just echoes all too common hype, its fallacies and the plain misunderstanding: but I will not take the time to go through it line by line, which is all I could give you, unless you rather stop lying and you rather show some respect, not for me but for the discipline. Otherwise, please feel free to just have it as you like it, I do not need to convince anybody, not on these matter, not anymore...

Julio

[Ulrich Neumerkel]

Jan Burse <janb...@fastmail.fm> writes:
>I guess the ISO standard shouldn't be found on the
>net, you must buy it. Putting it on the net is probably
>a copy right breach. Its nevertheless leaking on the net.
>Not sure whether it is some preprint:
>
>http://wwwdh.cs.fau.de/IMMD8/Lectures/LOGIK/isoprolog.pdf

The actual standard is only available by the respective
standardization bodies.

http://stackoverflow.com/tags/iso-prolog/info
http://stackoverflow.com/a/10914371/772868

Above pdf is CD2:1993 which got latexed in 1996. Please read
the introduction. CD1, CD2 have all been distributed freely.
Even some part of the DIS. But all these are working drafts only.

It shows only why ISO is so sceptical about free distribution of
drafts: They get never removed from the Internet - so the
dissemination of inaccurate information is perpetuated by
this individual ad infinitum.

[Jan Burse]

ulr...@mips.complang.tuwien.ac.at (Ulrich Neumerkel) schrieb:

> Above pdf is CD2:1993 which got latexed in 1996. Please read
> the introduction. CD1, CD2 have all been distributed freely.
> Even some part of the DIS. But all these are working drafts only.

Aha, Ok.

Thanks for clarifying.

[rupert...@googlemail.com]

We are in agreement; the language is ok not amazing; it is used in an undisciplined fashion and that is the worst of it. As someone said, all OO programming is, is just a way to write spaghetti code in a more sustained fashion than we could before it came along.

But I'm interested to know, what is this discipline you speak of? Can you summarize what your engineering discipline is? What language might support it better? Is it possible to even have a language that can only be used in a disciplined way, or is a lack of discipline always going to be a problem.

If I wanted my accounts done, I'd get a qualified accountant. If I wanted a house designed, I would pay a qualified architect. A bridge? A chartered structural engineer. So why do I look around the room I am sitting in and not see even one qualified IEEE software engineer? Only a few people with degrees in the subject, a lot of people with backgrounds in science or technical stuff, but usually a few that segwayed from Economics or History or somesuch. And then of course there is the Mumbai crew, like monkeys trying to randomly write Shakespear on a thousand typewriters. Well the demand for employees is high and the money is good so it is no surprise. But I think software engineering suffers somewhat from professional qualification issues; it would be to the advantage of those of us who are better qualified to try and get professional software engineering qualifications, and to promote them as a baseline for entry into our industry. This is what Parnas did, he described the term "software engineering" as an unconsummated marriage, and sat his professional exams.

[rupert...@googlemail.com]

On Sunday, April 12, 2015 at 9:18:08 AM UTC+1, Jan Burse wrote:
> I guess you are aware, that you are adressing the human-parsability
> of the language and not the machine-parsability. I think Julio Bad
> Ass is claiming that the machine-parsability is hard, i.e. that
> it is difficult to write a parser for Prolog.

What is it that makes it hard? Is it just the redefinable operator precedence or is it something else?

I wrote a mini-parser to handle dynamic operator precedence, it works ok, but I think it is not ISO compliant:

http://tinyurl.com/ne9gcdn

> What concerns human-parsability, there is already a nice document
> giving advice:
>
> Coding Guidelines for Prolog
> Michael A. Covington et al.
> last revised 17 May 2011
> http://arxiv.org/abs/0911.2899
>
> You will probably find some of the practice you have already
> mentioned.

Helpful, thanks.

Rupert

[Julio Di Egidio]

[Cross-post and follow-up to comp.software-eng.]

<rupert...@googlemail.com> wrote in message
news:88a02c27-2af2-4149...@googlegroups.com...

> On Monday, April 13, 2015 at 1:22:35 PM UTC+1, Julio Di Egidio wrote:
>> On Monday, April 13, 2015 at 12:17:15 PM UTC+1, rupert...@googlemail.com
>> wrote:
>>
>> > Quit being a whining baby Julio, and tell us what your vision of a
>> > better language is?
>>
>> I have already told you and quite clearly that the language per se is the
>> least of the problems. Your post just echoes all too common hype, its
>> fallacies and the plain misunderstanding: but I will not take the time to
>> go through it line by line, which is all I could give you, unless you
>> rather stop lying and you rather show some respect, not for me but for
>> the discipline. Otherwise, please feel free to just have it as you like
>> it, I do not need to convince anybody, not on these matter, not
>> anymore...
>

> We are in agreement; the language is ok not amazing;

We have certainly seen worse, and engineering problems are certainly vastly
more complex than just a programming language: on the other hand, I'd argue
that it is a very poor choice for the programming class, neither high-level,
nor low-level...

> it is used in an undisciplined fashion and that is the worst of it.

No, again, a programming language (that is not completely a showstopper, of
course) has only marginal relevance to the success of an engineering
endeavour, i.e. to the success of real production: first, there are actually
many languages involved in any piece of real development (and if one does
not forget that there is also analysis and design, there are actually so
many "languages" involved, some formal, most not even formal); second, any
languages are rather elements of platforms, and a platform as a whole rather
determines technical effectiveness; last but most important, all technical
aspects are in fact always the least critical: in software engineering, as
and more than in any other engineering, the human factor, i.e. people and
their requirements, is the true critical factor and the source of all
intrinsic, a.k.a. non-eliminable, complexity.

> As someone said, all OO programming is, is just a way to write spaghetti
> code in a more sustained fashion than we could before it came along.

Said by people who can write no better than spaghetti code to begin with.
There is rather a problem I call "OO uber alles", which is the real problem
with OO in general, that it has been misunderstood, mystified, and, of
course, oversold: to begin with, and as already mentioned, any non-trivial
system is rather written in a mixture of languages, in fact, in a mixture of
paradigms: declarative, imperative, functional, maybe even some bits of
logical (I do not have statistics at hand, but these exist and show for
instance that the role of declarative is usually vastly underestimated,
etc.). But, in particular, the idea that one can reduce all coding of a
system to one single paradigm is broken; the idea that OO is the best such
paradigm is even more broken; in fact, the idea that OO most immediately
models reality is even more than just broken (OO is actually the furthest
from reality); and, last but by no means least, architectural and
construction patterns such as the various instances of
model-driven/domain-driven (and the so many notions then needed to support
that picture, the truly fake complexity) are in fact incarnations of a
monolithic idea of systems that is the opposite of anything sensible
(indeed, just think modularity), and the opposite of anything that can have
a chance to really "work"...

> But I'm interested to know, what is this discipline you speak of? Can you
> summarize what your engineering discipline is?

Software engineering: not just my invention. My reference manual remains R.
Pressman, Software Engineering - A Practitioner's Approach, but beware that
mine is 4th edition (1997), then even in Pressman I find a little bit of
dilution... still one of the best reference points.

> What language might support it better?
> Is it possible to even have a language that can only be used in a
> disciplined way, or is a lack of discipline always going to be a problem.

As it should now be clear, I would not consider these the right questions to
ask.

> If I wanted my accounts done, I'd get a qualified accountant. If I wanted
> a house designed, I would pay a qualified architect. A bridge? A chartered
> structural engineer. So why do I look around the room I am sitting in and
> not see even one qualified IEEE software engineer? Only a few people with
> degrees in the subject, a lot of people with backgrounds in science or
> technical stuff, but usually a few that segwayed from Economics or History
> or somesuch. And then of course there is the Mumbai crew, like monkeys
> trying to randomly write Shakespear on a thousand typewriters. Well the
> demand for employees is high and the money is good so it is no surprise.
> But I think software engineering suffers somewhat from professional
> qualification issues; it would be to the advantage of those of us who are
> better qualified to try and get professional software engineering
> qualifications, and to promote them as a baseline for entry into our
> industry. This is what Parnas did, he described the term "software
> engineering" as an unconsummated marriage, and sat his professional exams.

I have always been in favour of a strict regulation of software engineering:
by all means, yes, software engineering should not be any different than
other engineerings, including the level of responsibility. On the other
hand, I can see few "very big" problems to solve before that can happen:
first, the situation is so compromised that we cannot expect any agreement,
not even on which the most fundamental principles of the discipline are (and
the state of the academia is not any less pitiful than it is the state of
the industry as a whole). Case in point, I do have my "book", it is just a
distillation of good old principles, plus my own findings, plus necessarily
the debunking of all bandwagons, but would you or anybody ever abide to it?
I mean, who is going to decide what the "discipline" exactly is, *at this
point*, i.e. after at least 20 years of heavy speculations and misguidance
and the totally compromised discipline and market I keep mentioning?
Moreover, I still think it is much more of a matter of the big players'
interests: you know, beside that software is not even sold, software is
"special" (all knowledge engineering is) and, to make a long story short,
this is much more about whether ideas are free vs. bread...

Julio

[Jan Burse]

Hi,

Julio Di Egidio schrieb:

> are actually many languages involved in any piece of real development
> (and if one does not forget that there is also analysis and design,
> there are actually so many "languages" involved, some formal, most not
> even formal); second, any languages are rather elements of platforms,
> and a platform as a whole rather

Thats why the JVMS7 thing is an interesting piece. Prolog
wasn't used for programming on some platform. It was used
as a result of analysis and design, i.e. a specification.

I already wrote this here:

Jan Burse wrote 05.04.15 11:50:

> My hypothesis is that Prolog (not GNU Prolog) was
> used as a specification. Specification means:

> So specification might include concept
> of operation, requirements and architecture,
> detailed designs, etc.. using methods
> like use cases, feature maps, etc..
>
> http://en.wikipedia.org/wiki/V-Model

So judging Prolog purely from the point of view
of a real programming language might be not the
right approach. Especially because of its logic
programming inheritance.

I guess we have here a typical case of can't see
the forest for the trees because of some software
engineering war.

Bye

[j4n bur53]

Whoa, it seems that the ability of attribute variables
to model cyclic structures seems to be explicitly
used in certain designs:

Question on SO:
How to represent directed cyclic graph in Prolog
with direct access to neighbour verticies

Answer on SO:
Answer by mat from 2012:
http://stackoverflow.com/a/10101483/502187


Jan Burse schrieb: