Path: ...!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Mild Shock Newsgroups: comp.lang.prolog Subject: =?UTF-8?Q?Re:_Did_Lifeware_Kill_Scryer_Prolog_CLP=28Z=29_=3f_=28Was?= =?UTF-8?Q?:_A_harsh_wind_is_blowing_into_the_face_of_Prolog_now=e2=80=a6_[F?= =?UTF-8?Q?ORTRAN_/_TIOBE_Index_for_May_2024]=29?= Date: Sat, 27 Jul 2024 12:09:38 +0200 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 27 Jul 2024 10:09:37 -0000 (UTC) Injection-Info: solani.org; logging-data="446179"; mail-complaints-to="abuse@news.solani.org" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 Cancel-Lock: sha1:ZuUySvPPcSt6/5a9N/yazgOJM6c= X-User-ID: eJwFwYEBgDAIA7CXwNGC5whl/59ggkPnZBAMXNynnKnpBKhTGKo58EnzelYBV5+oUnAd1aZv3ZQWG2/PDz/WFTI= In-Reply-To: Bytes: 4369 Lines: 92 Hi, The factor is smaller if the source has anyway a diversity of strings. If the source has a lot of redundant strings the factor is higher. You can explore Prolog compilation techniques that further deduplicate, but these compilation technqiques are best appplied by a more broader view, i.e. sharing numbers and compounds as well. Only looking at strings is possibly not worth the effort. But if you cross compile you don't have to do anything anyway. If I cross compile Dogelog Player to Java, the Jave byte code class format has a constant pools, so the Java compiler does the deduplication of strings for you. A cross compiled Datalog with a lot of foo, bar, baz, ..- foo(bar, baz) :- .... .... Will have a compilation output that uses a constant pool, and the strings in itself foo, bar, baz, etc.. will be shared. So the factor is again very low for cross compiled artefacts. Not sure what Python and JavaScript do, they might do a constant pooling as well. The constant pooling is very known for Java byte code class format the output of Java compilers, it was already there in the beginning. Bye Mild Shock schrieb: > Hi, > > Whats then more disturbing, if you try picking subparts > of the parsing string, and integrate them in the > parse tree, i.e. your AST. > > You then definitively lock the whole parsing source. But > the parsing source might be a couple of predicate > definitions, with constant arguments as found in Datalog: > > foo(bar, baz) :- .... > ... > > The old school non sharing approach would be to have > an atom table and you have then deduplicated foo, bar, > baz, etc... in one place and the source doesn't get > > locked. There is a also a new school, which I started > with Jekejeke Prolog and continued with Dogelog Player. > You don't share and you don't atom table. > > If you don't use atom table, you might have copies > in your code of foo, bar, baz etc.. But this is only > a small factor, the used memory is still lower than > > locking the whole source. And some Java versions have > string deduplication garbage collection under the hood now. > I am not sure what Python and JavaScript do. > > But so far I think the small factor of extra memory > usage is not an issue. > > Bye > > Mild Shock schrieb: >> Hi, >> >> But such a criteria is not satisfied in parsing, >> especially if you use the more advanced last call >> optimization and not only tail recursion optimization. >> >> As soon as parsing is deterministic, you can >> leave behind the string part that you already parsed. >> So you would need a special sharing that is kind of >> >> a weak sharing that can free some head part. There is >> no such problem of freeing the head part, if you use >> proper cons cell based lists for parsing. >> >> But naive substring sharing doesn't work for Prolog. >> It will unnecessarely lock the whole string always. >> Whereas a cell based parser can drop >> >> already parsed parts. >> >> Bye