Re: Fwd: Re: [9fans] samuel (fwd)

Re: Fwd: Re: [9fans] samuel (fwd)

[Bengt Kleberg]

> what terrible languages are you envisioning that would be so
> difficult for humans to read as to _require_ the use of external
> help?  the language
> 
> 	#!/bin/rc
> 	cat $* | tr '^@' '()' | lisp
> 
> would benefit from ^-@ matching, but aside from contrived examples
> i can't understand what more you want your text editor to do.

I would like for the text editor to tell me (with a single click) where
the start/end of a construction (be it function/if/while/...) is, if i
am at the end/start. sort of balancing the parantheses(sp?).
this is only neccessary if the language is not always visually balanced, like
a few languages are (ex: python).


> The various ML dialects share the same flaw in their syntax.
> They lack a simple property I call editor friendliness.  An editor
> friendly language has the property that a simple calculation
> is all that is needed to locate the beginning of an expression when
> one is at the end of an expression.
> 
> As you can guess, Lisp is a very editor friendly language.  
> Because of this fact, an experienced Emacs user realizes
> nearly all of the benefits of structure based editing without
> suffering from its restrictions.
> 	- John D. Ramsdell
> 
> The various Lisp dialects share the same flaw in their syntax.
> They lack a simple property I call human friendliness.  A human
> friendly language has the property that syntactic constructs are
> different enough from one another that a simple visual inspection
> is all that is needed to locate the beginning of an expression when
> one is at the end of an expression.
> 
> As you can guess, Lisp is a very human unfriendly language.
> Because of this fact, an experienced Lisp user realizes that it
> is virtually impossible to write Lisp programs of any size without
> substantial mechanical assistance.
> 	- Andrew Koenig
> 

if the 'human friendly language' allows free formatting of 'syntactic
constructs' it will be _very_ difficult for 'a simple visual
inspection' to _always_ 'locate the beginning of an expression when one
is at the end of an expression'. IMHO.

(btw, i normally write lisp programs with the expectation of having
'substantial mechanical assistance' in saveing/running them. it is
therefore prefectly ok, i think, to assume the presence of such
assistance.)


bengt

Re: Fwd: Re: [9fans] samuel (fwd)

[Douglas A. Gwyn]

Bengt Kleberg wrote:
> I would like for the text editor to tell me (with a single click) where
> the start/end of a construction (be it function/if/while/...) is, if i
> am at the end/start. sort of balancing the parantheses(sp?).
> this is only neccessary if the language is not always visually balanced, like
> a few languages are (ex: python).

I have recently run into the following style:

#if some_condition /* { */
....
#else /* } comment about new condition { */
....
#endif /* } */

This turns out to be very helpful for brace-matching editors like sam
(when double-clicking on the "inside" of a brace).

Re: Fwd: Re: [9fans] samuel (fwd)

[George Michaelson]

> I have recently run into the following style:
> 
> #if some_condition /* { */
> ....
> #else /* } comment about new condition { */
> ....
> #endif /* } */
> 
> This turns out to be very helpful for brace-matching editors like sam
> (when double-clicking on the "inside" of a brace).
> 

"I'm sorry, you have a non-matching brace in your comment. compilation
 halted at line xxxxx."

god, I miss the PL/1 computed goto sometimes...

-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

"Douglas A. Gwyn" wrote:
> I have recently run into the following style:
> 
> #if some_condition /* { */
> ....
> #else /* } comment about new condition { */
> ....
> #endif /* } */

I'll remember that.  It's gotta be cheaper than emetics.

Re: Fwd: Re: [9fans] samuel (fwd)

[Thomas Bushnell, BSG]

ggm@apnic.net (George Michaelson) writes:

> "I'm sorry, you have a non-matching brace in your comment. compilation
>  halted at line xxxxx."
> 
> god, I miss the PL/1 computed goto sometimes...

Lol.  GCC actually supports a close extension; you can store labels in
appropriately typed variables and then goto them.

Re: Fwd: Re: [9fans] samuel (fwd)

[ozan s yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

> Lol.  GCC actually supports a close extension; you can store labels in
> appropriately typed variables and then goto them.

yeah, that and some other extensions (eg. nested functions a la pascal)
that have failed to make it to any other C compiler [or standard] in the
last decade. we have great time scraping them off of any code we find
them in, assuming we have to keep that code. :)

oz

Re: Fwd: Re: [9fans] samuel (fwd)

[Andrew Simmons]

>Lol.  GCC actually supports a close extension; you can store labels in
>appropriately typed variables and then goto them.
>
I believe gcc is also the only compiler to support the computed "come from"
statement?

Re: Fwd: Re: [9fans] samuel (fwd)

[Thomas Bushnell, BSG]

ozan s yigit <oz@blue.cs.yorku.ca> writes:

> "Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:
> 
> > Lol.  GCC actually supports a close extension; you can store labels in
> > appropriately typed variables and then goto them.
> 
> yeah, that and some other extensions (eg. nested functions a la pascal)
> that have failed to make it to any other C compiler [or standard] in the
> last decade. we have great time scraping them off of any code we find
> them in, assuming we have to keep that code. :)

Ah well, such is the way of success, isn't it?

Re: Fwd: Re: [9fans] samuel (fwd)

[ozan s yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

> > yeah, that and some other extensions (eg. nested functions a la pascal)
> > that have failed to make it to any other C compiler [or standard] in the
> > last decade. we have great time scraping them off of any code we find
> > them in, assuming we have to keep that code. :)
> 
> Ah well, such is the way of success, isn't it?

well, humpty-dumptyism aside, i observe that the earlier experimentation
seems to be dying down. it also helps to have other compilers like sun's
workshop to assist in the cleanup.

oz

Re: Fwd: Re: [9fans] samuel (fwd)

[Thomas Bushnell, BSG]

ozan s yigit <oz@blue.cs.yorku.ca> writes:

> "Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:
> 
> > > yeah, that and some other extensions (eg. nested functions a la pascal)
> > > that have failed to make it to any other C compiler [or standard] in the
> > > last decade. we have great time scraping them off of any code we find
> > > them in, assuming we have to keep that code. :)
> > 
> > Ah well, such is the way of success, isn't it?
> 
> well, humpty-dumptyism aside, i observe that the earlier experimentation
> seems to be dying down. it also helps to have other compilers like sun's
> workshop to assist in the cleanup.

It's a little bizarre to hear Plan-9-ers arguing that C programs
should strictly conform to the "standard compiler interface", since,
after all, Plan 9 relishes not supported the "standard OS interface".

Re: Fwd: Re: [9fans] samuel (fwd)

[ozan s. yigit]

Thomas Bushnell:

> It's a little bizarre to hear Plan-9-ers arguing that C programs
> should strictly conform to the "standard compiler interface", since,
> after all, Plan 9 relishes not supported the "standard OS interface".

plan-9-ers argue nothing of the kind, so far as i'm aware. i happen to be a
part-time plan9-er with about fifteen years of gcc, so i feel i can comment
on the compiler, its successes and failures, as needed. alas, time's up. :)

oz
---
++?????++ Out of Cheese Error. Redo From Start.

Re: Fwd: Re: [9fans] samuel (fwd)

[Douglas A. Gwyn]

ozan s yigit wrote:
> google. search for message id 35E79AA5.602796A4@null.net

No, that was the one I already quoted.  There was a more extensive
example, I'm fairly sure..

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

Howard Trickey wrote:
> my nearly full-time work these days is living inside Microsoft's
> Visual Studio, doing C++, with a singing-dancing C++ mode that mostly
> just gets in the way.

Been there with Visual C++ [writing C] -- ick.

Re: Fwd: Re: [9fans] samuel (fwd)

[Douglas A. Gwyn]

Howard Trickey wrote:
> my nearly full-time work these days is living inside Microsoft's
> Visual Studio, doing C++, with a singing-dancing C++ mode that mostly
> just gets in the way.

My "favorite" is the language-savvy automatic formatter that doesn't
let you write approximate outlines then go back and clean them up,
but insists on immediately fleshing out everything while you're
typing.  To some extent MS Word does this (by default in its newest
editions); ever try to highlight exactly a particular word or phrase
only to have the "smart" editor suck in the adjacent spaces as well?
I think in the long run time would have been saved by not having such
"help".

Re: Fwd: Re: [9fans] samuel (fwd)

[ozan s yigit]

"AMSRL-CI-CN" <gwyn@arl.army.mil> writes:

> Many years back I posted to sci.crypt an example of the use of
> those tools in (intermediate level) cryptanalysis.  I can't seem to
> find it via DejaNews, though.

google. search for message id 35E79AA5.602796A4@null.net

oz

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

Andrew Simmons wrote:
> It's easier to cheat, and look up the answer in TPOP chapter 9.

I don't want to pollute sam, but given I know samuel is out there
I just thought it would be quicker.  Editors should edit text.

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

Russ Cox wrote:
> As far as Python is concerned, I've been happy
> with g alone.  Boyd, what did you want samuel to do
> besides grep for things?

Oh, I just saw emacs and it could zap to classes.

I do, coincidentally, have a script called 'g' and an script called 'pb'.

The later acts like plumb, 'cos I'm cursed to use lunix (sic).

Soon, I shall probably do all my work on plan 9.

Odd bit of work needs to get done _before_ that.

I like some of acme's ideas, but I just can't use it (sam suits me fine).

Re: Fwd: Re: [9fans] samuel (fwd)

[Russ Cox]

> if plan9/inferno switched to beeing implemented in something-else, that
> did not use ',",`,[,{,(,<, i strongly belive (IMHO, ok?) that a
> language mode would be developed.

what terrible languages are you envisioning that would be so
difficult for humans to read as to _require_ the use of external
help?  the language

	#!/bin/rc
	cat $* | tr '^@' '()' | lisp

would benefit from ^-@ matching, but aside from contrived examples
i can't understand what more you want your text editor to do.

russ

The various ML dialects share the same flaw in their syntax.
They lack a simple property I call editor friendliness.  An editor
friendly language has the property that a simple calculation
is all that is needed to locate the beginning of an expression when
one is at the end of an expression.

As you can guess, Lisp is a very editor friendly language.  
Because of this fact, an experienced Emacs user realizes
nearly all of the benefits of structure based editing without
suffering from its restrictions.
	- John D. Ramsdell

The various Lisp dialects share the same flaw in their syntax.
They lack a simple property I call human friendliness.  A human
friendly language has the property that syntactic constructs are
different enough from one another that a simple visual inspection
is all that is needed to locate the beginning of an expression when
one is at the end of an expression.

As you can guess, Lisp is a very human unfriendly language.
Because of this fact, an experienced Lisp user realizes that it
is virtually impossible to write Lisp programs of any size without
substantial mechanical assistance.
	- Andrew Koenig

Re: Fwd: Re: [9fans] samuel (fwd)

[Howard Trickey]

You may be right, but the language mode would not have been
done here at Bell Labs (IMHO, ok, but I know the guys involved),
nor would it likely to have been "bought back" if developed outside.

I just did a bunch of programming in Erlang, using sam, and didn't
feel the need for a language mode.  And no, it isn't because I don't
know what such a mode could do ... unfortunately, for various reasons,
my nearly full-time work these days is living inside Microsoft's
Visual Studio, doing C++, with a singing-dancing C++ mode that mostly
just gets in the way.

- Howard Trickey

Bengt Kleberg:
> if plan9/inferno switched to beeing implemented in something-else, that
> did not use ',",`,[,{,(,<, i strongly belive (IMHO, ok?) that a
> language mode would be developed.

Re: Fwd: Re: [9fans] samuel (fwd)

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> Subject: Re: Fwd: Re: [9fans] samuel (fwd)
> From: anothy@cosym.net
...deleted
> i don't think this has anything to do with prefering C-style
> languages. ',",`,[,{,(,< (any others?) all work the same way. i

i belive that acme, et al, gets away with (ie, nobody thinks it needs
it) having no language mode (or whatever this thing is called that
makes an editor programming language sensitive) just because it is used
by programmers codeing in c(-style) language(s).

if plan9/inferno switched to beeing implemented in something-else, that
did not use ',",`,[,{,(,<, i strongly belive (IMHO, ok?) that a
language mode would be developed.


bengt

Re: Fwd: Re: [9fans] samuel (fwd)

[David Rubin]

Russ Cox wrote:
> 
> I just looked at the cscope documentation.
> As Rob said, you can get 90% of cscope from
> grep -n, which is convenient to alias as `g':

Of course, cscope is a lot faster than grep when you have thousands of
files in your tree...

	david

-- 
If 91 were prime, it would be a counterexample to your conjecture.
    -- Bruce Wheeler

Re: Fwd: Re: [9fans] samuel (fwd)

[AMSRL-CI-CN]

"rob pike" <rob@plan9.bell-labs.com> wrote in message
news:3cb3dded4b8cad85cd6887800a46bc25@plan9.bell-labs.com...
> This all drives home my position on these matters, which is that
> general purpose tools that work well together almost always trump
> special purpose tools such as language-specific ones.  And even when
> they don't, they win overall by being applicable to domains far beyond
> the reach of the special-purpose ones.

Indeed!  I think the main reason Unix was such a hit was that it
provided a relatively complete and well integrated text-file tool kit
along with means to conveniently combine the tools.
Many years back I posted to sci.crypt an example of the use of
those tools in (intermediate level) cryptanalysis.  I can't seem to
find it via DejaNews, though.  I did find a posting where I gave
examples of how one's own small custom programs can be
effectively combined with the standard toolkit
(typo corrected in this reprint):

 $ # Find anagram of NABAAN:
 $ anabet < /usr/pub/words > analist
 $ echo NABAAN | anabet # also illustrates what anabet does
 AAABNN NABAAN
 $ grep '^AAABNN ' < analist
 AAABNN BANANA

 $ # Find keyword corresponding to transposition key 3 1 8 2 7 6 5 4:
 $ transkey < /usr/pub/words > keylist
 $ grep '^3 1 8 2 7 6 5 4:' < keylist
 3 1 8 2 7 6 5 4: CARBOLIC

Fwd: Re: [9fans] samuel (fwd)

[Andrew Simmons]

>(A reasonable grep, even without a regexp library to hand, can be done in
a few dozen
>lines of C.  An exercise for the reader.)

It's easier to cheat, and look up the answer in TPOP chapter 9.

Re: Fwd: Re: [9fans] samuel (fwd)

[Russ Cox]

As far as Python is concerned, I've been happy
with g alone.  Boyd, what did you want samuel to do
besides grep for things?

Re: Fwd: Re: [9fans] samuel (fwd)

[anothy]

//acme/wily shows its preference for c (style languages) by
// the ease one can check if/for/while/case/... balance by
// clicking inside '{'.

i don't think this has anything to do with prefering C-style
languages. ',",`,[,{,(,< (any others?) all work the same way. i
think it's more an issue of using the generality principle
again. acme doesn't have to know anything about any
language to match { to } and so on; to understand the Fun
or case declaration you gave would require special
understanding of the language. for example, acme knows
nothing of how to highlight an entire case clause, because
it knows nothing of the language.
ア

Re: Fwd: Re: [9fans] samuel (fwd)

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> From: "Matt H" <matt@proweb.co.uk>

 
> aha despite this useful convention Boyd wants his to understand Python code
> not C where such things are not so easily grepped for
> 

acme/wily shows its preference for c (style languages) by the ease one
can check if/for/while/case/... balance by clicking inside '{'.
ex: is this (Erlang) code properly balanced?

Fun = fun(X) ->
	R = case X of
		1 ->
			ok;
		_ ->
			fail
		end,
	R,
	end,
end,
Fun(1).



bengt

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

> aha despite this useful convention Boyd wants his to understand Python code
> not C where such things are not so easily grepped for

OTOMH I think it's a 'orrible problem.

Re: Fwd: Re: [9fans] samuel (fwd)

[rob pike]

This all drives home my position on these matters, which is that
general purpose tools that work well together almost always trump
special purpose tools such as language-specific ones.  And even when
they don't, they win overall by being applicable to domains far beyond
the reach of the special-purpose ones.  Acme can integrate mail rather
nicely; samuel never had a chance - even a reason to go - in that
direction.

You can have your IDEs; I'll take a good text editor any day, even if
I have to write my own grep to go along with it.  (A reasonable grep,
even without a regexp library to hand, can be done in a few dozen
lines of C.  An exercise for the reader.)

-rob

Re: Fwd: Re: [9fans] samuel (fwd)

[Russ Cox]

I just looked at the cscope documentation.
As Rob said, you can get 90% of cscope from
grep -n, which is convenient to alias as `g':

	g% cat g
	#!/bin/rc
	
	flags=()
	while(! ~ $#* 1 && ~ $1 -*){
		flags=($flags $1);
		shift
	}
	switch($#*){
	case 0
		echo 'usage: g [flags] pattern [files]' >[1=2]
		exit usage
	case 1
		grep -n $flags -- $1 *.[Cbchm] *.cc *.py *.tex *.ms /dev/null \
			|[2] {grep -v '^grep: can''t open \*' >[1=2]; status=''}
	case *
		grep -n $flags -- $* /dev/null
	}

The set of files in ``case 1'' changes from person to
person.  My acme window tags are littered with
g this and g '^that'.

If you don't mind typing small regular expressions
like '^that' and your source code conforms to the 
``function names in definitions start at the beginning
of the line'' convention, then you can usually get 
by without cscope.

If you want to remember a little more, you could
try adding some stuff to g to find function/macro
declarations:

	g% cat h
	#!/bin/rc
	
	rfork e
	if( ~ $#* 0){
		echo 'usage: h name [files]' >[1=2]
		exit usage
	}
	
	pattern=$1
	shift
	files=($*)
	if(~ $#files 0)
		files=(*.h ../port/*.h /sys/include/*.h /sys/include/*/*.h)
	datadef='^[a-z].*[ 	]'^$pattern^'\('
	definedef='^#define[ 	]+'^$pattern^'[ 	]'
	g '('^$datadef^')|('^$definedef^')' $files \
		|[2] {grep -v '^grep: can''t open ' >[1=2]; status=''}
	g% 

or data definitions:

	g% cat def
	#!/bin/rc
	
	rfork e
	if( ~ $#* 0){
		echo 'usage: def name [files]' >[1=2]
		exit usage
	}
	
	pattern=$1
	shift
	files=($*)
	g '^[ 	]*[a-zA-Z0-9_]+[ 	a-zA-Z0-9,]*[, 	]'^$pattern^'($|[^a-zA-Z0-9_])' $files
	g% 

or uses of a particular symbol:

	g% cat sym
	#!/bin/rc
	
	rfork e
	if( ~ $#* 0){
		echo 'usage: sym name [files]' >[1=2]
		exit usage
	}
	
	pattern=$1
	shift
	files=($*)
	g '(^|[^a-zA-Z0-9_])'^$pattern^'($|[^a-zA-Z0-9_])' $files
	g% 

I wrote these last three in a hurry last night just 
for fun, inspired by having seen something similar
a while back in a screen shot in the help paper,
but I'm not sure whether I'll actually use them
or just stick with g.  h might be useful since it
provides a different set of default files.  def and 
sym seem less useful, since g usually turns up
what I want with a minimum of noise.

The other nice thing about g instead of cscope-like
things is that your searches can be arbitrary regexps
rather than whatever cscope happens to provide;
for example, how do you g 'dmactl = 0' in cscope?

Russ

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

rob pike wrote:
> Sam is atext editor.  Voilà .

Je suis complètement d'accord avec toi.

Re: Fwd: Re: [9fans] samuel (fwd)

[George Michaelson]

> Semantics-directed editing, now that might be something special.

Visual Basick IDE tries to tell you what arguments you want to put into
the function it thinks you are trying to write. 

I think thats a mis[-take | -mischievious idea | -understanding of what I want]

%PRESS TAB TO COMPLETE%

(sigh)

-George

Re: Fwd: Re: [9fans] samuel (fwd)

[rob pike]

> What do you say rob, could you suggest how? ;)

I don't remember exactly what samuel did, and I'm not much of a fan of
syntax-directed editing anyway.  Text is text.  C is text.  Sam is a
text editor.  Voilà.

Sam's `understanding' of C as plain text has never felt like a
limitation to me.  Sometimes I run grep in another window to figure
something out.  Use grep -n in *.[ch] and plumb the result and you're
probably 90% of the way to samuel.

Semantics-directed editing, now that might be something special.

-rob

Re: Fwd: Re: [9fans] samuel (fwd)

[Sam]

What do you say rob, could you suggest how? ;)

I would actually be more interested in seeing this work with
acme, if nothing but for the novelty of it.

Sam

---------- Forwarded message ----------
Date: Thu, 28 Feb 2002 21:43:26 -0500
From: John Puttress <puttress@comcast.net>
To: sah@softcardsystems.com
Subject: Re: Fwd: Re: [9fans] samuel

Sam,
Samuel is an integration of Rob Pike's sam editor with Joe Steffen's cscope
browser.  I believe that both tools are available externally, and I have to
believe that Rob's sam has been ported to plan9.  Unfortunately, samuel was
never released externally, and I cannot legally distribute this source
outside of Lucent... and since I am no longer working for Lucent, I
wouldn't be able to start the process to release it...  if you can find an
advocate inside of Lucent, I can direct them to the source.

On the otherhand, Rob's sam editor is a very powerful tool on its own, and
could be used with cscope to do many of the same searches samuel does,
without changing code.  I'm sure Rob could suggest how.

John

Sam Hopkins wrote:

> Mr. Puttress,
>
> There has been discussion on the 9fans mailing
> list as of late of an editor named samuel you
> wrote some time ago.  I'm quite interested in the
> source code and getting it to run on plan9.
>
> Would you be willing to share the source with
> me?
>
> Cheers,
>
> Sam Hopkins
>
> ----------  Forwarded Message  ----------
> Subject: Re: [9fans] samuel
> Date: Thu, 28 Feb 2002 10:04:21 -0500
> From: Jim Kelleman <kelleman@lucent.com>
> To: sah@softcardsystems.com
>
> His home email address is puttress@comcast.net
> He did get another job, so he probably won't read your
> mail until the evening.
>
> jim
>
> Sam Hopkins wrote:
> > I am interested in the code.  Please forward me his
> > home e-mail address.
> >
> > Cheers,
> >
> > Sam
> >
> > On Thursday 28 February 2002 08:19, Jim Kelleman wrote:
> > > Mr. Puttress (John) was my supervisor until he retired
> > > this past summer.  If you're interested in the code,
> > > send mail to me privately and I'll give you his home email address.
> > >
> > > jim
> > >
> > > rob pike wrote:
> > > > > Yes please, release it. I'd love to try samuel.
> > > >
> > > > I have no idea where the code is.  It was done by a Mr. Puttress,
> > > > who was working for Ted Kowalski at the time.  I don't know where
> > > > those people are any more, but they might be at AT&T.
> > > >
> > > > I looked around the Lucent and AT&T sites with no luck.  The code
> > > > has never been part of our tree, as far as I know.
> > > >
> > > > -rob
>
> -------------------------------------------------------

Re: Fwd: Re: [9fans] samuel (fwd)

[Matt H]

> If you don't mind typing small regular expressions
> like '^that' and your source code conforms to the
> ``function names in definitions start at the beginning
> of the line'' convention, then you can usually get
> by without cscope.

aha despite this useful convention Boyd wants his to understand Python code
not C where such things are not so easily grepped for

unless you count grep ^(\t| )?def +that
as small :)

There's also the added bonus that includes in python come in two styles AND
don't include the filename extension

from filename import function
import filename

I did hanker myself after a python class/function browser but was too busy
writing the code to start writing the meta code!

M