HDTenEightyP/NetNews huggingface dataset:
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: LOGO riddle/task/thing to think about
Date: 1 Oct 92 13:59:52 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu

s2874066@techst02.technion.ac.il (Eyal Peleg) writes:
>  Draw a vertical line that starts from home [0 0] and ends at [0 90],
>  This line should not be a continuous one but should be 4 pixels on and 1 off
>  something like "---- ---- ---- ---- ---- ...."

Boy, when I read this message the first time I thought "that's trivial, what's
the deal?"  But when I actually tried it I learned two things, one was the
fencepost problem about pixels, and the other is that it's even harder in
Berkeley Logo, because it tries to set the aspect ratio according to what the
graphics hardware says is right, and for my CGA laptop that comes out some
non-integer ratio.

(Berkeley Logo tries to arrange things so that FD 100 fits within the
splitscreen graphics area.  For CGA that turns out to mean that one
vertical turtle step is only (about) half a screen pixel.  If I make it
exactly half a screen pixel, I can get the desired dotted line with
PD FD 2 PU FD 3!!  If I use the setting that Berkeley Logo comes up with
on its own, there's no way I can get uniform dotted lines.  You can't win.)
From: mills@athena.lkg.dec.com (George Mills)
Newsgroups: comp.lang.logo
Subject: Re: HELP WANTED: LSRHS version of LOGO (DOSLOGO)
Date: 6 Oct 92 19:44:22 GMT

johns@macadam.mpce.mq.edu.au (John Savage) writes:


>I would like to hear from anyone running the LSRHS LOGO, so I can compare
>notes on some mysterious behaviour I have found in the version I downloaded
>from cher.media.mit.edu as DOSLOGO.

>Specifically, I found that PRINT RANDOM 10000 works reliably, but
>PRINT RANDOM 32767 works only about one time out of every five times I
>execute it. (32767 is the largest positive integer for 16 bits).  Some
>integer arguments are not accepted at all - I can live with that, but I
>would like the largest range of random numbers, so why does RANDOM 32767
>run only erratically??

I'm not sure what's going on here. I will probably not fix it but I may
give an answer or a work around. My only interest is for MswLogo and it
turns out rnd crashes it (ouch). Thanks for reporting this. Note the source
is availble for DosLogo.


>Furthur, the ASCII function is strange.
>To return the ASCII value of the character "0", one should use
>PRINT ASCII "0 , but this returns a number cycling through this set, one
>value at a time, every time it is run:
>232 232 124 124 90 90 158 1158 28 28 !!!   None of these is correct.
>To get the correct answer, I can use PRINT ASCII 0 ; but this cannot
>be extended to finding the ASCII value of "D", etc.

Try this,

make "letter "a
ascii :letter
make "letter "b
ascii :letter

There does seem to be a problem with using ascii directly, this
should work around it and you can you can probably write a logo
routine yourself (e.g. myascii) to fix it). For some reason it does
works on MswLogo (Same exact code). Interestingly the Ascii command is
not documented anywhere? How did you know it existed?

>Apart from these oddities, I like it.

>-----------------------------------
>John Savage
>School of Maths, Physics, Computing & Electronics,
>Macquarie Univerity.
>Sydney.  Australia.                email: johns@macadam.mpce.mq.edu.au
>-----------------------------------
Newsgroups: comp.lang.prolog
From: brady@cs.tcd.ie (Michael Brady)
Subject: Re: a question about read
Followup-To: comp.lang.prolog
Organization: University of Dublin, Trinity College
Date: Wed, 30 Sep 1992 13:45:58 GMT

In article <23753@alice.att.com>, pereira@alice.att.com (Fernando Pereira)
wrote:
[About DEC10 Prolog's behaviour of read/1 and get/1] etc.
 but

> according to the manual and my recollection both read(X) and get(C)
> advance the input appropriately and try to unify the object scanned
> with their argument. If the unification fails, the advancing of the input
> stream is not undone, but the calls fail.

My memory, which could easily be wrong, was that if for read(Term), it read
in the first term it came across, and failed if that term wasn't unifiable
with Term. It would also report syntax errors...
For get0(Char), it read in a character, and if the character didn't unify
with Char, it would advance to the next character and try again, ad
infinitum until the right character was read.
Is my memory playing tricks on me?

The real question is what is the most desirable action in these cases. I
agree with Lee about read/1, but how about get0/1 and get/1?

---------------------
Mike Brady
Computer Science Department, Trinity College Dublin, Ireland
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.prolog
Subject: Re: Writing portable code.
Date: 30 Sep 92 08:02:43 GMT
	<14758@goanna.cs.rmit.oz.au> <ALBERTO.92Sep29141859@karna.cs.umd.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: alberto@cs.umd.edu's message of 29 Sep 92 18:18:59 GMT

In article <ALBERTO.92Sep29141859@karna.cs.umd.edu> alberto@cs.umd.edu (Jose Alberto Fernandez R) writes:
   [ example of a preprocessor written in Prolog deleted ]

   As I said in my previous message, the problem with this is that you
   are mixing your declarative program, with the declaratios of how the
   code must be process in a particular installation.

You consider it a problem, I consider it an advantage.


   I don't like that, I believe that the programmer should be able to
   clearly distinguish between the two.

I prefer that one language be used wherever possible.


   That facilitates the portability of software to different
   architectures.

So does using the same language for both tasks.

When all said and done, you prefer the separate language approach and
I prefer the single language approach (preferably using partial
evaluation).  I'm not out to convince anyone that the single language
approach is best and am willing to be convinced by the other side of
the argument, however I've yet to see a technical argument for it
(i.e. something other than "I don't like ...").  Is there a technical
argument of any sort or is this a purely subjective issue?

bevan
Newsgroups: comp.lang.prolog
From: magnus@ii.uib.no (Magnus Alvestad)
Subject: Small Prolog Interpreter
Organization: Dept. of Informatics, University of Bergen
Date: Thu, 1 Oct 92 04:41:19 GMT

There has been talk here of a very compact prolog interpreter.
Has anyone got the source code for it? A compiler would be 
just as interesting, but less realistic I suppose.

Reply by mail, I will summarize if there are replies.

-Magnus

Newsgroups: comp.lang.prolog
From: gerry@coral.cs.jcu.edu.au (Gerry Trinidad)
Subject: Re: Graph Traversal
Keywords: Prolog, Graph
Organization: James Cook University
Date:  4 Oct 92 22:31:23 GMT

In <1605@newsserver.cs.uwindsor.ca> arindam@cs.uwindsor.ca (Arindam Das) writes:

>Hi !

>I am implementing an automated mask layout generator for dynamic CMOS
>circuits.

[Text Deleted]

>Now, In my program i need to do complex traversal of the graph.
>I being at ease in using Prolog (Quintus Prolog), am using it
>comfortably and i am finding that i can develop the code pretty
>quickly.

I think you had just give the reason why you should use Prolog 
instead of C. It is easier to develop the code.

>However I have to defend the use of Quintus Prolog instead of C.

Aside from the fact it is easier to write in Prolog, the resulting
code is easier to maintained even by other persons.

I could even add that I would rather have a slow and correct program
than a fast code that I am not really sure of. But are Prolog programs
uniformly slow across the board. An article in the Janaury 1992 issue of
the Computer magazine (of IEEE Comp Society) has something to say along
this line.

Some might say that Prolog is a nice toy language suitable for small
eligant toy problems. The book "Practice of Prolog" might offer some
counter arguments. [Edited Leon Sterling, MIT Press 1990].

=======

Some closing comments :

I believe that Prolog, like other programming languages, has its
good and bad points. It just sad that misconception and prejudice 
ambivalence towards Prolog is still wide spread these days.

Why should a Prolog programmer has to justify using Prolog instead of
language X? 


Newsgroups: comp.lang.prolog
From: cianca@di.unipi.it (Paolo Ciancarini)
Subject: conf. on applications of Prolog
Organization: Dipartimento di Informatica, Universita' di Pisa
Distribution: comp
Date: Wed, 30 Sep 1992 14:46:23 GMT

I need the complete reference
fro the proceedings of the Conf.
on Applications of Prolog, held in London
this year in April. Who was the editor
and the publisher of the proceedings?

Many thanks

Paolo Ciancarini

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Paolo Ciancarini  (cianca@di.unipi.it)
tel:     +39 50 510264 fax: +39 50 510226
address: Dip. di Informatica - University of Pisa
Newsgroups: comp.lang.prolog
From: lee@munta.cs.mu.OZ.AU (Lee Naish)
Subject: Re: a question about read
Organization: Department of Computer Sci, University of Melbourne
Date: Tue, 29 Sep 1992 02:10:47 GMT

In article <10468@uqcspe.cs.uq.oz.au> pjr@cs.uq.oz.au writes:
>
>How does your favourite Prolog behave in the following situation
>
>query:  ?- read(f(X)).
>
>I already know the following:
>
>Nu-Prolog :  
>      continue to input until the input is of the form f(term).
>
>Qu-Prolog & IC-Prolog: 
>      fail - 3 and f(X) don't unify.
>
>LPA MacProlog : 
>      fail - argument of read must be a variable at the time of call.

Oops, this looks like a bug in NU-Prolog.  read/1 should read a single
term (with no backtracking) then attempt to unify it with the argument.

There is a general principle that

	?- pred(...X...), X = Some_term

should behave in the same way as

	?- pred(...Some_term...)

except were this really isn't feasible.  One case where its not feasible
is meta level operations such as write(X) and assert(p(X)).  Here X is
best thought of as a meta level variable rather than an object level
variable and instantiating it gives a different meaning (unfortunately
Prolog doesn't really distinguish between the object and meta levels,
making the meaning of such things less than crystal clear :-).
Another case is where there would be an infinite number of intermediate
answers, such as Y is 1 + X.  If you have coroutining, the thing to do
here is delay the call until X is further instantiated (resulting in the
same behaviour for the two goals).  Without coroutining the best you can
do is trap to an error handler.  However, if you can execute the first
(less instantiated) case sensibly you should always be able to execute
the second case sensibly and you should get the same behaviour.

Is there a case for read/1 returning an error when called with a
non-variable (as in MacProlog)?  I suspect the reason for deciding to
make this an error is that you nearly always call read with a variable
and cases when you don't are most commonly due to mistakes in the
program.  However, this is rather ad hoc.  An implementor may decide to
make division by a negative number an error for the same reason.  It is
easier for everyone if there a a small number of general principles
rather than lots of special cases.  Is there a general principle that
can support the MacProlog behavior?  I think there is, but it requires
the object and meta levels to be distinguished.  When we call read(X), X
should be thought of as a meta variable.  When a meta variable is
compared to another (meta) term, unification is generally *not* the
operation we want but thats what you get with parameter passing in
Prolog.  pred(...Some_term...) should be equivalent to pred(...X...),
meta_equals(X, Some_term).  The exact kind of equality desired is not
clear, but giving an error seems like a better idea than using
unification.

In summary: for simplicity and compatability it should fail, but bear in
mind that Prolog meta level (and I/O) is pretty stuffed from a logical
point of view.

	lee
From: opalla@owl.informatik.uni-dortmund.de (Rudolf Opalla)
Newsgroups: comp.lang.prolog
Subject: logic-functional
Date: 30 Sep 1992 13:49:28 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: owl

I don't know if this is the correct group, but if anyone is interested - I
have posted the logic-functional language-system ALF to ftp.germany.eu.net
(simpson.germany.eu.net).

ALF (Algebraic Logic Functional programming language)
is a language which combines functional and logic programming techniques.
The foundation of ALF is Horn clause logic with equality
which consists of predicates and Horn clauses for logic
programming, and functions and equations for functional programming.
Since ALF is an integration of both programming paradigms,
any functional expression can be used in a goal literal and
arbitrary predicates can occur in conditions of equations.
The abstract machine is based on the Warren Abstract Machine (WAM)
with several extensions to implement narrowing and rewriting.
In the current implementation programs of this abstract machine are
executed by an emulator written in C.

You can find it in the path "/pub/programming/languages/LogicFunctional".
There are three files which contain:
  - alf_sys.zoo:  - Documentation (englisch),
                  - C-Sources (for the emulator) - should work with all 16/32
                    bit-systems,
                  - Compiled version of the preprocessor (see below)
                  - Compiled version of the compiler         "
                  - some basic modules
                  - small examples

  - alf_pp.zoo:   ALF-Sources for the preprocessor (type-checking, manages a
                  modul-concept, ...)

  - alf_comp.zoo: ALF-Sources for the compiler, translates the preprocessors
                  output to:
                  - a file which is executable through the emulator
                  - to WAM-like instructions (text)

 ____________________________________________________________
|                                                            |
| Rudolf Opalla  -  opalla@julien.informatik.uni-dortmund.de |
|____________________________________________________________|
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: postfix operators - does anyone need them?
Date: 6 Oct 92 12:07:10 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <1992Sep30.205620.5130@quintus.com>, pds@quintus.com (Peter D. Schachte) writes:
> I haven't seen any formal proposals for a distfix extension; does anyone
> have one?

The DEC-10 Prolog library contains a file DISTFI.PL which is a Prolog
parser adapted from READ.PL and supporting distfix operators.  It is
based loosely on CGOL and was written to support a functional language
that was implemented on top of DEC-10 Prolog.  There should still be a
copy in the Edinburgh Prolog library, and there ought to be a copy at
Quintus.  The basic idea was to extend op declarations:

	distfix_op(Priority, [{x,y}]f[{x,y}], List, Term)

the x or y on the left refers to an operand preceding the first keyword;
the x or y on the right refers to an operand following the last keyword;
I forget about the internal operands but they were probably 999 or x.

e.g.	distfix_op(950, fy, [if,A,then,B,else,C],
		if_then_else(A,B,C)).

I never got around to writing an unparser.

> Does it support required and optional term parts?

In a way.  Just like WonderPop on the dear old DEC-10, you can have
any number of distfix declarations for the same leading keyword.  So
you can have
	distfix_op(950, fy, [if,A,then,B],
		if_then_else(A,B,true)).
A "required" part is just a part common to all the patterns.
An optional part is a part which is not common to all the patterns.

> Repeated parts?

No.

> What kind of flexibility does it give users to control the
> structure of the (sub)term ultimately returned?

Shown above.

> It seems to me like a hard problem to design such an extension.

No.  Remember, WonderPop had the "forms" facility which was a way of
letting Pop programmers specify new keyword-based forms, e.g.
	form for I: ident in E: expr do S: stmts enddo;
	   map(lambda I; S end, E)
	endform;
might define iteration over a list.  There was also the CGOL parser to
look at (the Edinburgh DAI library had a copy of a paper by Pratt which
made it very clear) and there were people around working with functional
languages who wanted it.  My DISTFIX.PL was deemed adequate at the time,
but of course syntax error handling was dismal and unparsing wasn't
implemented at all.  It's also worth pointing out that READ.PL and
DISTFI.PL are written in Prolog.  The distfix reader could backtrack all
over the place, it was _not_ a deterministic parser.  If you want to
design a distfix extension which is easy to parse deterministically,
that's another matter.  (It has been done, though.  Ask in comp.compilers
about compilers with run-time-extensible syntax.)

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
Newsgroups: comp.lang.prolog
From: jamie@cs.sfu.ca (Jamie Andrews)
Subject: JICSLP/Washington,DC -- share room?
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 30 Sep 1992 21:37:04 GMT

     Does anyone want to share a room at JICSLP in Washington?

     The nights I (male, non-student) will be there are from
Nov. 8 to Nov. 14 inclusive.  If you plan to be there for most
of those nights, and would be interested in sharing a room, let
me know.  Hotel reservations have to be in by Oct. 18.

     The rates are $127/night for a single and $148/night for a
double room.  Your half of a double room would work out to
$74/night, so you save $53/night by sharing.

--Jamie.
  jamie@cs.sfu.ca
"Standard brain-toy bullet list for any GnuAge grokabilly shopping trip"
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.lang.prolog
Subject: Re: Prolog with pc serial
Date: 26 Sep 92 00:31:03 GMT
X-Maildoor: WaflineMail 1.00r


   Bert Edens was espousing about 'Prolog with pc serial',
   on [09-23-92  01:26] to All!
 BE> Thanks for the suggestions. This is for a PC, and is actually some
 BE> stuff I'm hoping to work on for a BBS package/door. The logic, etc.,
 BE> just can't be beat, and was wanting to use it instead of some of the
 BE> other languages...

    It makes a lot of things easier!  Since the language does
    most of the work.

        Stephen Cyberman@Toz.Buffalo.NY.US
        Scripted at Thu  09-24-1992  12:32:50

... Patience availeth much. What can you get for impatience?
--- Blue Wave/QWK v2.10
From: cduguay@lcraft.ersys.edmonton.ab.ca (Claude Duguay)
Newsgroups: comp.lang.prolog
Subject: retract*all
Date: 30 Sep 92 16:57:06 GMT
Organization: LogiCraft Corp, Edmonton, AB, Canada

This may seem sill or I might be missing part of this conversation but
would it not be easier and just as portable to use a simpler 
implementation of retractall/retract_all rather than creating elaborate 
solutions to emulate compiler directives:
        
        myretractall(Term) :-
                retract(Term),
                fail.
        myretractall(_).

Appologies for any naivety resulting from my focus on PDC Prolog and 
restricted experience with other versions of Prolog.


Claude Duguay              cduguay@lcraft.ersys.edmonton.ab.ca 
Newsgroups: comp.lang.prolog
From: andrewt@watson.ibm.com (Andrew Taylor)
Subject: Re: How to cleanup side effects after cut?
Date: Mon, 28 Sep 1992 15:27:03 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

In article <TED.92Sep24112332@lole.nmsu.edu> ted@nmsu.edu writes:
>but in fact, the whole program can be rewritten automatically, and if
>you are willing to do some flow analysis, it can be rewritten to avoid
>overhead when you don't need it.

This automatic rewriting may not be possible if call/1 is present.

Andrew Taylor
From: csa09@seq1.keele.ac.uk (Paul Singleton)
Newsgroups: comp.lang.prolog
Subject: Re: Writing portable code.
Date: 27 Sep 92 14:00:52 GMT
Organization: Keele University, England

From article <1a3srjINNsgm@darkstar.UCSC.EDU>, by kjell@cse.ucsc.edu (Kjell Post):
 
> Let me explain by an example what I'm looking for.  I want to write a
> program that works for both SICStus Prolog and Sepia.  The problem is
> that I need to retract all clauses foo/n when the program is started.
> Now, in SICStus the procedure is called retractall/2, but in Sepia it
> is retract_all/2.  That extra underscore (or absence of it) is really 
> annoying!  So I'd like to hear about efficient and portable tricks to
> write code that works in both languages.

    invent some novel name for the facility you require
    (e.g. retract_all_matching_unit_clauses)

    write your portable code in terms of this

    write compatibility libraries for each target Prolog implementation
    e.g.
	retract_all_matching_unit_clauses( X) :-
		retractall( X).

    to port to Prolog X:

	link your source with the Prolog X compatibility library (linking
	in Prolog is particularly trivial: 'cat' does it)

	feed the result through a general-purpose partial evaluator
	(e.g. Dan Sahlin's Mixtus) to eliminate the redundant procedures.

----
  __   __    Paul Singleton (Mr)           JANET: paul@uk.ac.keele.cs
 |__) (__    Computer Science Dept.        other: paul@cs.keele.ac.uk
 |  .  __).  Keele University, Newcastle,    tel: +44 (0)782 621111 x7355
             Staffs ST5 5BG, ENGLAND         fax: +44 (0)782 713082
Newsgroups: comp.lang.prolog
From: micha@ecrc.de (Micha Meier)
Subject: Re: Efficiency
Reply-To: micha@ecrc.de
Organization: European Computer-Industry Research Centre
Date: Mon, 5 Oct 1992 10:21:42 GMT

In article 28120@athena.cs.uga.edu, mcovingt@aisun3.ai.uga.edu (Michael Covington) writes:
>  - Efficiency of execution
>       (That's right, if you're using backtracking and unification then
>        your program will probably run as fast under Prolog as under any
>        other language.  We once ported a simple Prolog list processing
>        routine into Pascal as a test, and got a factor-of-14 *slowdown*!)

It is nice that People really do believe in Prolog, but there must be a mistake here.
The fact that you use unification and backtracking does not make your program
faster, it may simplify the algorithm, though. When one rewrites list processing
procedures to C, one certainly gets a significant speedup, maybe 3 - 10.
You must have dome something funny in your Pascal translation, or it was
a very slow Pascal. In fact it is unification, backtracking, and logical variables,
i.e. the particular Prolog features, that make it slower than other languages.
The current compiler technology moves towards eliminating this overhead by
recognizing deterministic code in place of backtrackable one, and assignments
and tests in place of the unification, but it will take some time till we get there.

--Micha

---
Micha Meier			------------------------------------------------
ECRC, Arabellastr. 17		The opinions expressed above are private
D-8000 Munich 81		and may not reflect those of my employer.
micha@ecrc.de, Tel. +49-89-92699-108, Fax  +49-89-92699-170

Newsgroups: comp.lang.prolog