Re: Ann: SWI-Prolog 7.1.9

On 27/02/2014, at 18:02, Jan Wielemaker <[email protected]> wrote:

> On 02/27/2014 06:39 PM, Jose F. Morales wrote:
>>    It is not optional (well, there is --traditional). I think that the Ciao
>>    modular and strict architecture is a great piece of engineering. I
>>    prefer to keep things `just available' though. That approach surely has
>>    disadvantages, but quite likely it contributed a lot in the popularity
>>    of the system.
>> 
>> 
>> You are definitely right that 'just available' is a great idea to push
>> the language forward. However, that implies that each SWI version is
>> potentially implementing a slightly different language/dialect.
> 
> To some extend, yes.  In practice the backward compatibility seems to
> be pretty reasonable, even with the major changes of V7.
> 
>> I wonder if there is any best practice for specifying the expected
>> dialect, system version, etc. Per-module declarations are precise but
>> too noisy for medium/large projects. Is it possible to specify the
>> requirements to the 'pack' definition in SWI?
> 
> You refer to these packs [1]?  They can specify requirements, but not
> in enough detail to be very meaningful.  In my experience, :- if does
> a good job writing programs and libraries that run over multiple
> versions that are not compatible.  In most cases
> 
> :- if(\+current_predicate(xyz/2)).
> 
> xyz(X, Y) :-
> 	<write a replacement>.
> 
> :- endif.
> 
> That nicely deals with the the introduction of xyz in version V. The
> only issue is that you cannot deal with code that is syntactically
> invalid. That can be a problem if you want to write code that runs in V7
> using dicts or quasi quotations and other Prolog systems. In such cases,
> I guess the only way is not to use dicts or use another syntactic
> abstraction and implement that with and without dicts. Possibly
> ECLiPSe's idea of having a hook that provides term rewriting after
> read_term/3 is a good idea after all. When I heart about it I was
> sceptical.

Logtalk (necessarily) implements its term-expansion mechanism on top of read_term/3. This is often key to deal with otherwise incompatible differences between the supported back-end Prolog compilers. This includes built-in predicates with different argument order, proprietary directives, and (other) Prolog extensions.

For Prolog itself, given that read_term/3 already have a list of options as argument, I would expect that adding one for invoking term-expansion could likely be done without significant (if any) performance downsides.

> p.s. We could consider ignoring syntax errors in excluded conditional
> code?

I used to dream about this one :-)

> The problem is of course that it needs to find the :- endif. or :-
> elif or :- else. I guess we can define some way around, but it would be
> harder to get that accepted by all systems providing conditional
> compilation.

Cheers,

Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:[email protected]>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------