Re: Ann: SWI-Prolog 6.5.3

On 11/22/2013 01:38 AM, Richard A. O'Keefe wrote:

>> Ideally, we'd have static tools for that, but unfortunately these are
>> still not widespread.
>
> The DEC-10 type checker was public domain, 30 years ago.
> I guess people were really serious about NOT wanting it.

My point.  I think we want some form of typing, but not this way.

>>> Can we please consider "getting rid of [a|b]" a *non*-problem?
>>
>> That is absolutely not a non-problem.
>
> I guess this is one of those YMMV issues.  For me, this has not
> been a common mistake since about 1982, while on the other hand
> there have been times when I have wanted a compact data structure
> and have used [_|_] as a *PAIR* (not *LIST*) construction
> internally.

I think I'd call this `hacking'.  It doesn't even buy you anything
in SWI-Prolog :-)

>> This is not a hypothetical issue, but a frequent source of frustration.
>
> I am astonished that it should be "frequent".  Perhaps a good naming
> convention really helps.

I think it has little to do with naming conventions.  It happens quite
regularly for me as well as with people who I sometimes help debugging.

> Yes, but all you're doing now is increasing the number of such
> predicates by one, *sometimes*.

Which I still consider a move in the right direction.

> If I were to grant that [a|b] were a serious problem,
> then I'd be looking for a serious solution.

Sure.  Not now though.

>> The main point of strings is that they are *not* lists
>
> OK.  If you think strings are a good data type, shouldn't they have
> more operations?  And should the manual still be saying
>	new code should consider using atoms
> ?  Would it be a good idea to replace string_to_list/2 (which name
> suggests conversion that goes ONLY left to right) with
>	string_codes(?String, ?Codes)
>	string_chars(?String, ?Chars)
> like atom_codes/2 and atom_chars/2?  Shouldn't there be a
> number_string/2 to go with number_{codes,chars}/2?
> Would it be a good idea to
> document that/whether strings work in UTF-8, and whether "characters"
> in the documentation of string_length/2 and sub_string/5 means "bytes"
> or "Unicode code-points"?  Would it be a good idea to offer the
>     span_left(String, Set, Before[, Length[, After]])
>     span_right(String, Set[[, Before], Length], After)
> predicates that Xerox Quintus Prolog did?  -- quite helpful for
> tokenising.

All that is the aim.  All atom_xxxx predicates will have their
string_xxxx counterpart.  I'm all in favour of adding some more
to make common tasks on strings easier.   As atoms, strings are
sequences of unicode code points, including 0.

> Strings in SWI Prolog look like, and are _documented_ like, something
> that was begun and then more or less abandoned except for backwards
> compatibility.  I had taken the "new code should use atoms" advice at
> face value.

That is definitely the case. As I recall it, they appeared in early
drafts of the ISO standard and I considered them a good idea. Then they
were dropped from the ISO standard, which caused me to backtrack. In
those days the system didn't have atom-GC and strings were a welcome
data type for some processing tasks, so I left them in, but without a
syntax. With atom-GC an unicode support I started to deprecate them. I
think that was a bad idea.

> Xerox Quintus Prolog, sitting on top of Interlisp-D, *had* to do
> something sensible with strings.  Other Prologs have also sat on top
> of a Lisp, and JekeJeke Prolog, amongst others, sits on top of Java.
> These systems too had *better* do something sensible with strings.
> Arguably, Web-friendly systems working with JSON need a text
> representation that doesn't look like a JSON array (and even with
> the 'chars' representation, you can't tell an empty chars-list
> from any other empty sequence), so strings may be thrust on us.
> Strings can handle Unicode-compatible case conversion in a way that
> mapping along a list would find difficult -- because Unicode-
> compatible case conversion needs the *whole* string to work with,
> not being single-code-point-at-a-time.
>
> You have made some good arguments for having a string data type and
> there are plenty of other arguments that could be made.  It's not
> ISO, but then, despite the clear need, neither are bignums or ratios
> ISO.
>
> Dash it, I think I've just argued myself into changing my mind.
> OK, I'm _still_ never going to use "foo" for anything but a list of
> codes, but I might be quite pleased to use `foo` for a string.

We had that discussion.  All in all it seems that most people think
we should `bit the bullet' and use a string notation that is used in
the rest of the world.  The current V7 prototype maps `...` to a
code list.  Not sure I want to keep that.  It does make some
porting tasks easier.

>> The double_quotes flag has no impact on the runtime.  It only
>> defines the resulting data structures from parsing "text" and it
>> does so on per-module basis.  So, if you have a module that
>> processes code lists and uses a lot of list processing predicates
>> with explicit "text" as arguments, you just declare that module
>> to parse this into code lists.
>
> OK, this is a documentation issue.  What I wanted is for the flag
> to be per-FILE, but it is documented as being per-MODULE, and with
> operator declarations hanging around at run time, it was natural
> to suppose that prolog-flag -- which _looks_ like a run-time flag
> was doing the same.

Scoping prolog flags is a bit of a mess as Paulo also explained.
Using module scope was a reasonable choice as it is also the case
for operators and some other flags (such as char_escapes).  It also
allows passing the module to read and write to use the syntax of
that module.

> We are told that character_escapes is "local to the module in
> which it is changed."
> (I'd like a declaration that is per-FILE.)
> We are told that double_quotes "is ---like character_escapes---
> maintained for each module."
>
> We are *not* told there what this actually means, and it seems
> that I misunderstood.  Also,
> we are *not* told that the apparently similar backquoted_string
> flag is maintained for each module, so maybe it isn't?  Shoud
> it not be just like the other two?

The flag back_quotes behaves the same as double_quotes (except
that it doesn't support `atom' from some historical reason as
well as I think that makes no sense at all.

	Cheers --- Jan