9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01 17:58 Russ Cox
  2002-03-05  9:22 ` Boyd Roberts
  0 siblings, 1 reply; 34+ messages in thread
From: Russ Cox @ 2002-03-01 17:58 UTC (permalink / raw)
  To: 9fans

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?



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-04 15:24 Bengt Kleberg
  2002-03-05  9:41 ` Douglas A. Gwyn
  0 siblings, 1 reply; 34+ messages in thread
From: Bengt Kleberg @ 2002-03-04 15:24 UTC (permalink / raw)
  To: 9fans


> 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



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-04 14:41 Russ Cox
  0 siblings, 0 replies; 34+ messages in thread
From: Russ Cox @ 2002-03-04 14:41 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-04 11:43 Bengt Kleberg
  2002-03-04 14:02 ` Howard Trickey
  0 siblings, 1 reply; 34+ messages in thread
From: Bengt Kleberg @ 2002-03-04 11:43 UTC (permalink / raw)
  To: 9fans


> 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



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-04  0:21 Andrew Simmons
  2002-03-05  9:34 ` Boyd Roberts
  0 siblings, 1 reply; 34+ messages in thread
From: Andrew Simmons @ 2002-03-04  0:21 UTC (permalink / raw)
  To: 9fans

>(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.




^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01 17:29 anothy
  0 siblings, 0 replies; 34+ messages in thread
From: anothy @ 2002-03-01 17:29 UTC (permalink / raw)
  To: 9fans

//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.
ア



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01 17:13 Bengt Kleberg
  0 siblings, 0 replies; 34+ messages in thread
From: Bengt Kleberg @ 2002-03-01 17:13 UTC (permalink / raw)
  To: 9fans


> 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



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01 16:15 rob pike
  2002-03-04 10:04 ` AMSRL-CI-CN
  0 siblings, 1 reply; 34+ messages in thread
From: rob pike @ 2002-03-01 16:15 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01 16:04 Russ Cox
  2002-02-02 17:05 ` Matt H
  2002-03-04 10:04 ` David Rubin
  0 siblings, 2 replies; 34+ messages in thread
From: Russ Cox @ 2002-03-01 16:04 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 34+ messages in thread
[parent not found: <rob@plan9.bell-labs.com>]
* Re: Fwd: Re: [9fans] samuel (fwd)
@ 2002-03-01  2:51 Sam
  0 siblings, 0 replies; 34+ messages in thread
From: Sam @ 2002-03-01  2:51 UTC (permalink / raw)
  To: 9fans

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
>
> -------------------------------------------------------



^ permalink raw reply	[flat|nested] 34+ messages in thread
end of thread, other threads:[~2002-03-08  9:59 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-01 17:58 Fwd: Re: [9fans] samuel (fwd) Russ Cox
2002-03-05  9:22 ` Boyd Roberts
  -- strict thread matches above, loose matches on Subject: below --
2002-03-04 15:24 Bengt Kleberg
2002-03-05  9:41 ` Douglas A. Gwyn
2002-03-05 10:04   ` George Michaelson
2002-03-06  9:51     ` Thomas Bushnell, BSG
2002-03-06 15:56       ` ozan s yigit
2002-03-07  9:56         ` Thomas Bushnell, BSG
2002-03-07 16:46           ` ozan s yigit
2002-03-07 17:55             ` Thomas Bushnell, BSG
2002-03-08  9:59               ` ozan s. yigit
2002-03-06 19:39       ` Andrew Simmons
2002-03-05 10:18   ` Boyd Roberts
2002-03-04 14:41 Russ Cox
2002-03-04 11:43 Bengt Kleberg
2002-03-04 14:02 ` Howard Trickey
2002-03-05  9:41   ` Douglas A. Gwyn
2002-03-05 10:42   ` Boyd Roberts
2002-03-04  0:21 Andrew Simmons
2002-03-05  9:34 ` Boyd Roberts
2002-03-01 17:29 anothy
2002-03-01 17:13 Bengt Kleberg
2002-03-01 16:15 rob pike
2002-03-04 10:04 ` AMSRL-CI-CN
2002-03-05  9:40   ` ozan s yigit
2002-03-06  9:51     ` Douglas A. Gwyn
2002-03-01 16:04 Russ Cox
2002-02-02 17:05 ` Matt H
2002-03-01 17:12   ` Boyd Roberts
2002-03-04 10:04 ` David Rubin
     [not found] <rob@plan9.bell-labs.com>
2002-03-01  6:20 ` rob pike
2002-03-01  6:34   ` George Michaelson
2002-03-01 12:04   ` Boyd Roberts
2002-03-01  2:51 Sam

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).