Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Announcement: Common Lisp Structure Editor

152 views
Skip to first unread message

Blake McBride

unread,
Aug 29, 2015, 3:33:24 PM8/29/15
to
I enhanced and converted an InterLisp structure editor provided in the
LISPF4 system to Common Lisp. It is located on github at:

https://github.com/blakemcbride/LispEdit

Blake McBride

menti...@gmail.com

unread,
Aug 30, 2015, 10:35:30 AM8/30/15
to
As a charter member of us Mad People of comp.lang.lisp at

http://devrel.zoomquiet.io/data/20080926113320/index.html

and as a brogrammer of Lisp-ready Strong AI at

http://ai.neocities.org/AiSteps.html

I congratulate you for your success.

Cheers,

Arthur T. Murray/Mentifex
--
Major goal in life: Trigger a Technological Singularity;
Minor goal: Overthrow the unelected government of China;
Minor goal: Win a Nobel Prize in Physiology or Medicine;
Minor goal: [X] Reunification of East and West Germany.

Rainer Joswig

unread,
Aug 30, 2015, 2:18:13 PM8/30/15
to
Don't take it as an offense, but what CL was that written in?

: is not acceptable as a symbol just so.

There is a DEFPACKAGE, but no IN-PACKAGE.

And so on...

Blake McBride

unread,
Aug 30, 2015, 2:55:59 PM8/30/15
to
Sorry. Added all the package stuff after-the-fact. Guess I need to fix it.

Thanks.

Blake

Rainer Joswig

unread,
Aug 30, 2015, 3:04:17 PM8/30/15
to
You might also want to take into account that output in Common Lisp
implementations can be buffered.
I'm pretty sure that for portable code you need to make sure that
output is actually done...
See FINISH-OUTPUT / FORCE-OUTPUT.

Blake McBride

unread,
Aug 30, 2015, 3:17:09 PM8/30/15
to
Probably not a bad idea, however, I've never seen a system that didn't
auto-flush when close is called (or implicitly called via with-open-file).


Rainer Joswig

unread,
Aug 30, 2015, 3:25:40 PM8/30/15
to
On 2015-08-30 19:17:03 +0000, Blake McBride said:
>
> Probably not a bad idea, however, I've never seen a system that didn't
> auto-flush when close is called (or implicitly called via
> with-open-file).

I'm not talking about files. All IO can be buffered: screen, terminal,
files, network, ...

If you print something on the screen like a prompt and then read, you
need to force the output after the print and before reading.

Blake McBride

unread,
Aug 30, 2015, 3:35:29 PM8/30/15
to
Actually, I am aware of that. I've seen the problem when using stdio.
That is why I used *query-io*. Haven't seen the problem with that.
Isn't that the whole purpose of *query-io* - not to buffer?

Anyway, my tests seem to indicate that *query-io* doesn't buffer. If an
instance where I am wrong is encountered, I'll add the flush.

Thanks.

Blake

Rainer Joswig

unread,
Aug 30, 2015, 3:56:01 PM8/30/15
to
On 2015-08-30 19:35:26 +0000, Blake McBride said:

> On 08/30/2015 02:25 PM, Rainer Joswig wrote:
>> On 2015-08-30 19:17:03 +0000, Blake McBride said:
>>>
>>> Probably not a bad idea, however, I've never seen a system that didn't
>>> auto-flush when close is called (or implicitly called via
>>> with-open-file).
>>
>> I'm not talking about files. All IO can be buffered: screen, terminal,
>> files, network, ...
>>
>> If you print something on the screen like a prompt and then read, you
>> need to force the output after the print and before reading.
>>
>
> Actually, I am aware of that. I've seen the problem when using stdio.
> That is why I used *query-io*. Haven't seen the problem with that.
> Isn't that the whole purpose of *query-io* - not to buffer?

There is no requirement to not buffer *query-io*.

>
> Anyway, my tests seem to indicate that *query-io* doesn't buffer. If
> an instance where I am wrong is encountered, I'll add the flush.

Atleast SBCL and ABCL buffer the query-io stream.


Blake McBride

unread,
Aug 30, 2015, 5:28:02 PM8/30/15
to
On 08/30/2015 01:18 PM, Rainer Joswig wrote:
Wow! How bad could it possible be? It worked in CLISP. I've now
corrected it and tested in sbcl, clisp, ccl, abcl, cmucl, gcl, and ecl.

Thanks for the feedback!

Blake

Pascal J. Bourguignon

unread,
Aug 31, 2015, 3:16:13 AM8/31/15
to
If you don't put IN-PACKAGE in the file, then the file will be loaded in
the current *PACKAGE* which might be the package named
"COMMON-LISP-USER".

clhs "2.3.5 Valid Patterns for Tokens"

says:

5. The consequences are unspecified if any other pattern of package
markers in a token is used. All other uses of package markers
within names of symbols are not defined by this standard but are
reserved for implementation-dependent use.


It happens that clisp exercises the freedom it has to read ":" as a
keyword with an emptyp name. Conforming representations for this
keyword are: :|| and KEYWORD:||.



Notice that once upon a time, clisp had a package nickname for the
KEYWORD package that was the empty string too. This definitely was not
conforming and has been removed. But it made ||:|| another
representation for KEYWORD:||. "" is a valid user package name.


(defpackage "" (:use "CL") (:export "RAILS"))
(defpackage "⊥" (:use "CL") (:export "RAILS"))
(not (eq '||:rails '⊥:rails))


--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Blake McBride

unread,
Aug 31, 2015, 9:42:37 AM8/31/15
to
I've began to notice some of this. Thanks for the complete history.

The editor should be fixed now.

Thanks!

Blake

Kaz Kylheku

unread,
Aug 31, 2015, 11:53:48 AM8/31/15
to
On 2015-08-30, Rainer Joswig <jos...@lisp.de> wrote:
> On 2015-08-29 19:33:14 +0000, Blake McBride said:
>
>> I enhanced and converted an InterLisp structure editor provided in the
>> LISPF4 system to Common Lisp. It is located on github at:
>>
>> https://github.com/blakemcbride/LispEdit
>>
>> Blake McBride
>
> Don't take it as an offense, but what CL was that written in?
>
> : is not acceptable as a symbol just so.

That's too bad! In my TXR Lisp dialect, it denotes a keyword symbol
with the name "", and has special uses.

It looks good in a mixture with the consing dot:

;; denotes optional arguments:

(lambda (required1 required2 : optional1 optional2 . rest) ...)

;; In a call, explicitly requests default value for optional,
;; eliminating "95%" of the need for keyword args:

(function req1 req1 : opt2)

;; colon return out of tree-case case means "please fall through
;; to the next case":

(tree-case obj
((foo (bar) . xyzzy) (if (eq foo 'huh)
(do-whatever foo bar xyzzy)
:)) ;; foo is not huh; case not applicable
(...))

In many situations when you need a self-evaluating special third value
to accompany t and nil, you can use colon instead of inventing something
ad-hoc, so long as it doesn't conflict with the standard uses of colon.

Colon symbol: damned useful.
0 new messages