Re: Extended DCG?

Hi Samer,

Ok.  I see two developments:

   - Introduction of real strings in V7 (compatible to ECLiPSe and quite
     likely YAP at some point).
   - Future directions to a more (soft) typed language.

There has also been fierce fights about this in the ISO group.  I don't
know the current status.

I see several solutions:

   1. Keep phrase checking and add a new non-checking predicate.
   2. Use Markus' state interface (exploiting push-back and a
      one-element list).
   3. Remove checking and add some checking library that
      wraps phrase calls with type checking.
   4. Only disallow string objects in phrase/3.
   5. Auto-convert string objects in phrase/3 to code lists.

(1) is probably the best from a type-checking viewpoint. I don't know
how to name the predicate (you seem to struggle too). I think the name
should not refer to `gammar'. You are threading state that has nothing
to do with the notion of grammars. Your bodies must also be limited as
(list) literals make no sense. To me, it still seems you're misusing an
implementation vehicle for something it was not supposed to do.  In
my experience that is asking for a breakdown sooner or later.

(2) seems pretty elegant to me.  I don't really see your argument
for `another layer of meta predicates'.  I see two rather simple
predicates that we should be able to inline if necessary.  The
only overhead should be a list cell.

(3-5) makes we can never introduce more validation later.

(3) leaves people doing phrase("he", "hello") completely in the
dark with a 'false'.  Unless they load some library, but that
probably only happens after significant frustration.

(4) might be a practical solution.  Feels hacky though.  Why can I
use an atom as a state, but not a string?

(5) Would make many things work as before, but for the wrong reason.
If there was only phrase/2 I might have been in favor, but the result
below is hard to explain.

   ?- phrase("he", "hello", X).
   X = [108, 108, 111].

My preference goes to either (1) or (2), adding the predicates to
the system and properly documenting the issue.

Support/preference/other solutions?
Names for predicates if we go (1) or (2)?

	Cheers --- Jan

P.s.	Ideally, I'd like something else for threading state, such as
	Tom's coroutining proposal, or possibly something simpler.


On 02/12/2014 07:48 PM, Abdallah, Samer wrote:
> Hi all,
> I would just like to use this opportunity to request again that phrase/3 be
> allowed to work with arbitrary types in the last two positions, not just
> lists, or an alternative, say gphrase/3  (for generalised phrase), or
> rundcg/3 which works exactly like phrase/3 but allows arbitrary types.
> Or even better, put phrase/3 back how it was and introduce a type
> checking list_phrase/3 or safe_phrase/3 for people who want that.
>
> It used to be the case that an extended DCG for writing a transducer
> as  Alan would like, was easy to write using ordinary DCG notation.
> The type of the threaded argument would be a pair of lists (L,R)
> instead of just one list. In my DCG library I have some DCG rules for
> working with this conveniently. For example, operators (\<)//1 and (\>)//1
> apply a DCG phrase to the left or right member of the pair:
>
> :- op(800, \<, fy).
> :- op(800, \>, fy).
>
> \<(P, (L1,R), (L2,R)) :- phrase(P,L1,L2).
> \>(P, (L,R1), (L,R2)) :- phrase(P,R1,R2)
>
> Then you can do things like \< integer(X) to read an integer from
> from the left sequence and \> [int(X)] to write a term to the right, and so on.
> Alan's scenario is easily and efficiently dealt with.
>
> Forcing us to use lists for the arguments to phrase/3 forces an ugly
> encoding of the pair in a singleton list, e.g. as [(L,R)], and, if the list
> is [X] and we already have a bunch of predicates that want to work
> on X,  forces an unnecessary layer of meta-predicates to get through
> the wrapping.
>
> For the moment, I have deleted the two offending lines from boot/dcg.pl
> in my local installations, but of course, this is not good for the portability
> of my code!
>
> cheers,
> Samer
>
>
> (
> On 11 Feb 2014, at 16:51, Alan Baljeu <[email protected]>
>   wrote:
>> I have a scenario where I'm mapping a list to a second list, but it's not 1 to 1.  For this, it would be nice to use an extended DCG, that supports two independent lists.  Does such a thing exist?
>>
>> Alan Baljeu
>> -------------- next part --------------
>> HTML attachment scrubbed and removed
>> _______________________________________________
>> SWI-Prolog mailing list
>> [email protected]
>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <https://lists.iai.uni-bonn.de/pipermail/swi-prolog/attachments/20140212/e49a2d8e/attachment.bin>
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>