Home > Archive > Prolog > May 2006 > String is not string in SWI prolog , part/2.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
String is not string in SWI prolog , part/2.
|
|
| newser.bbs@bbs.ee.ncu.edu.tw 2006-05-24, 4:09 am |
| Last time , this topic was concluded that the string can't
be produced by directly written in the form of "...",
and it should be produced by procedures , eg
string_to_atom/2.
But the problem is not totally solved . Please look :
--------------------------------------------------------------------------------------
Welcome to SWI-Prolog (Multi-threaded, Version 5.2.13)
Copyright (c) 1990-2003 University of 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.
For help, use ?- help(Topic). or ?- apropos(Word).
1 ?- string_to_atom(S,'This is a test').
S = "This is a test"
Yes
2 ?- string_to_atom(S,'This is a test'),
| assertz(db_string(S)),
| tell('c:\\test.txt'),
| listing(db_string/1),
| told.
S = "This is a test"
Yes
3 ?- db_string(S).
S = "This is a test"
Yes
4 ?- db_string(S),
| string_concat(S,S,S2).
S = "This is a test"
S2 = "This is a testThis is a test"
Yes
5 ?- retractall(db_string(_)).
Yes
6 ?- db_string(S).
No
7 ?- consult('c:\\test.txt').
% c:\test.txt compiled 0.00 sec, 520 bytes
Yes
8 ?- string_concat(S,S,S2).
ERROR: string_concat/3: Arguments are not sufficiently instantiated
9 ?- db_string(S),
| string_concat(S,S,S2).
ERROR: string_concat/3: Type error: `atomic' expected, found `[84, 104,
105, 115, 32, 105, 115, 32, 97, 32, 116, 101, 115, 116]'
---------------------------------------------------------------------------
You can see that , there is problem in the step 9 , although the
identical
codes get allright in the step 4.
For more clarification , just look the contents of c:\test.tx:
++++++++++++++++++++++++++++++++++++++++
+
:- dynamic db_string/1.
db_string("This is a test").
++++++++++++++++++++++++++++++++++++++++
++
It takes the form of db_string/1 with a parameter made of string .
But it just compiles to something that causes string_concat out of
order.
So weird !
Maybe that is because things chages if saved by listing and retrieved
by consult/1. For circumvention from such possibility ,
the following topic happens.
| |
| Mauro Di Nuzzo 2006-05-24, 4:09 am |
| > For more clarification , just look the contents of c:\test.tx:
> ++++++++++++++++++++++++++++++++++++++++
+
>
> :- dynamic db_string/1.
>
> db_string("This is a test").
> ++++++++++++++++++++++++++++++++++++++++
++
>
I want to help you, but please have a little fantasy.
Forget to have created that file and look it like it was the first time.
I really do not see any string creation, and Prolog system do the same,
interpreting "This is a test" like a charcodes list.
Consider instead:
++++++
:- dynamic db_string/1.
db_string(S) :-
string_to_atom(S, 'This is a test').
++++++
Cheers - /\/\
| |
| newser.bbs@bbs.ee.ncu.edu.tw 2006-05-24, 4:09 am |
|
Mauro Di Nuzzo wrote:
> I want to help you, but please have a little fantasy.
> Forget to have created that file and look it like it was the first time.
> I really do not see any string creation, and Prolog system do the same,
> interpreting "This is a test" like a charcodes list.
I knew that and I have mentioned : things change if saved via listing
and retrieved via consult. Thus I try writeq/1 and read/1 for the
manual
says things can be read 'back' . But you can see the result in
the topic of ' read doesn't read back from writeq' : the manual just
tells a lie to the user.
> Consider instead:
>
> ++++++
> :- dynamic db_string/1.
>
> db_string(S) :-
> string_to_atom(S, 'This is a test').
> ++++++
of course these codes functions well.
And another way also works:
consult('c:\\test.txt'),
db_string(X), string_to_list(S,X).
Although we can get back the original string
via different methods, that is still not convenient.
In lisp , WRITE prints the value so that it could be
presented to READ to create the same value.
That is simple and convenient, because we don't
have to add extra codes , just have to do the simple
action of saving and reading.
In prolog , is there the same simple way as in lisp
for saving and reading data ? Or we just can't help
worry that we might forget some necessary codes?
>
> Cheers - /\/\
| |
| Mauro DiNuzzo 2006-05-24, 8:03 am |
|
You have to consider that Prolog has, let's say, its native types
(atoms and charcode-lists, regarding our discussion). These types can
be considered both identical to a "string" datatype. SWI Prolog
"string" type refer only to a different method of treating a string of
characters (for this topic please read SWI manual).
So, importantly, it is not necessary at all to create "string" datatype
in prolog, unless one wants to use those special functions for any very
particular purpose (and if so, please tell me what are your needs).
Probably you are just surfing SWI Prolog capabilities... consider to
look for something more interesting regarding SWI and Prolog in
general.
Cheers - /\/\
| |
| newser.bbs@bbs.ee.ncu.edu.tw 2006-05-24, 10:02 pm |
| Mauro DiNuzzo wrote:
> You have to consider that Prolog has, let's say, its native types
> (atoms and charcode-lists, regarding our discussion). These types can
> be considered both identical to a "string" datatype. SWI Prolog
Yes , I had this idea before . You can see my message (
http://groups.google.com.tw/group/c...d5317332bf?dmo=
de=3Dsource&hl=3Dzh-TW
) , I gave codes for getting line:
--------------------------------------------------------
assertz((get_line(L):-get_char(C),(C=3Dend_of_file->copy_term('',L);C=3D'\n=
'-> c=ADopy_term(C,L);get_line(L1),atom_conc
at(C,L1,L)))).
assertz((eof:- get_char(C),(C=3Dend_of_file,!;unget_cha
r(C),fail))).
---------------------------------------------------------
In these codes , you can see that I use atoms for strings ,
(see the atom_concat ?)
But I have read about inside lisp before , and it is said that
an atom was presented as an ID Number inside lisp . If this is
also true in prolog , my represenation for strings might cause
problems. Eg for an web page of thousands of lines ,
the number of atoms it created might become up to millions,
thus millions of ID Numbers will be wasted unnecessarily and
it might cause slow-down in compiling or interpretation of
my program.
Thus I think it is better using string.
As for the charcode-lists , it's very unsightful .So it is the
last way I'll use for presentation of strings.
> "string" type refer only to a different method of treating a string of
> characters (for this topic please read SWI manual).
> So, importantly, it is not necessary at all to create "string" datatype
> in prolog, unless one wants to use those special functions for any very
> particular purpose (and if so, please tell me what are your needs).
> Probably you are just surfing SWI Prolog capabilities... consider to
> look for something more interesting regarding SWI and Prolog in
> general.
>=20
> Cheers - /\/\
| |
| Pierpaolo BERNARDI 2006-05-25, 4:03 am |
| On Thu, 25 May 2006 03:56:14 +0200, <newser.bbs@bbs.ee.ncu.edu.tw> wrote:
> ) , I gave codes for getting line:
> --------------------------------------------------------
> assertz((get_line(L):-get_char(C),(C=end_of_file->copy_term('',L);C='\n'-> cĀ_opy_term(C,L);get_line(L1),atom_conca
t(C,L1,L)))).
>
> assertz((eof:- get_char(C),(C=end_of_file,!;unget_char(
C),fail))).
> ---------------------------------------------------------
> In these codes , you can see that I use atoms for strings ,
> (see the atom_concat ?)
swi has read_line_to_codes/[2,3], which can be used as a base.
I'd use:
newser_read_line(Stream,LineAsAtom,LineA
sCodes) :-
read_line_to_codes(Stream,LineAsCodes),
( LineAsCodes = end_of_file
-> LineAsAtom = end_of_file
; atom_codes(LineAsAtom,LineAsCodes
).
> But I have read about inside lisp before , and it is said that
> an atom was presented as an ID Number inside lisp . If this is
> also true in prolog , my represenation for strings might cause
> problems. Eg for an web page of thousands of lines ,
> the number of atoms it created might become up to millions,
> thus millions of ID Numbers will be wasted unnecessarily and
> it might cause slow-down in compiling or interpretation of
> my program.
This is not a problem in swi prolog.
In other prolog implementations, it may or may not be a problem,
depending on whether they do or do not do atom garbage collection.
P.
--
Anything below this line is being added by the newsserver
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
|
|
|
|
|