From: Masoud Pirnazar
Subject: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <9q0d9t$t50@dispatch.concentric.net>
does anyone have ideas on how to implement something like this:
(in-this-scope ...)
for example,
(in-this-scope let ((a 3) (b 9))) xxx
is the same as
(let ((a 3) (b 9)) xxx)
i.e. (in-this-scope aaa bbb ...) xxx is equivalent to (aaa bbb ...
xxx)
it could be used with (let-macro ...) and other forms that bring in new
definitions, without making the function
then you could do
(define (fcn)
(in-this-scope (let ((a 3)))
(do something-1)
(in-this-scope (let ((b 7)))
(do something-2))
which would be like
(define (fcn)
(let ((a 3))
(do-something)
(let ((b 3))
(do-something-2))))
a macro for in-this-scope would be ok, but i can't think of a way of doing
this without changing the basic reader/parser
"Masoud Pirnazar" <···········@apptek.com> wrote in message
···············@dispatch.concentric.net...
> does anyone have ideas on how to implement something like this:
>
> (in-this-scope ...)
>
> for example,
> (in-this-scope let ((a 3) (b 9))) xxx
> is the same as
> (let ((a 3) (b 9)) xxx)
>
I don't see how you can have this macro affect things that are outside of it
without making a global change...?
> i.e. (in-this-scope aaa bbb ...) xxx is equivalent to (aaa bbb ...
> xxx)
>
> it could be used with (let-macro ...) and other forms that bring in new
> definitions, without making the function
>
> then you could do
> (define (fcn)
> (in-this-scope (let ((a 3)))
> (do something-1)
> (in-this-scope (let ((b 7)))
> (do something-2))
>
> which would be like
> (define (fcn)
> (let ((a 3))
> (do-something)
> (let ((b 3))
> (do-something-2))))
>
And how would you distinguish when you wanted instead:
(define (fcn)
(let ((a 3))
(do-something))
(let ((b 3))
(do-something-2)))
BTW, what is (define ...) ?
> a macro for in-this-scope would be ok, but i can't think of a way of doing
> this without changing the basic reader/parser
>
Sounds like a lot of trouble to avoid a little trouble...
Lots of nesting is fine. What do you think of as excessive? I'm always
proudest when my functions end with 10+ closing parens ;-)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Kalle Olavi Niemitalo
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <87d73v8rg3.fsf@Astalo.y2000.kon.iki.fi>
"Coby Beck" <·····@mercury.bc.ca> writes:
> BTW, what is (define ...) ?
It is a definition syntax in comp.lang.scheme, where this was
cross-posted.
From: Kent M Pitman
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <sfw8zekw464.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
"Masoud Pirnazar" <···········@apptek.com> writes:
> does anyone have ideas on how to implement something like this:
Let me start by saying I think this is poor form because
the whole idea of Lisp style is that parens visually identify bounded
scope. The only "assignments" normally apply outward globally (unless
boxed by containing parens). You're fighting that whole principle.
Nevertheless, I'll answer your question in case it helps you learn something
about the mechanics of the language:
> (in-this-scope ...)
>
> for example,
> (in-this-scope let ((a 3) (b 9))) xxx
> is the same as
> (let ((a 3) (b 9)) xxx)
>
> i.e. (in-this-scope aaa bbb ...) xxx is equivalent to (aaa bbb ...
> xxx)
>
> it could be used with (let-macro ...) and other forms that bring in new
> definitions, without making the function
The only way to do this is to find the containing contours in which you want
to allow in-this-scope and modifying them. For example, if you want to
do this in a DEFUN body, you would write your own DEFUN that checked the
body for (in-this-scope...) and reshaped things into a LET that put the
parens in the place you should have put them in the first place.
But you wouldn't be able to use it elsewhere.
Consequently, IN-THIS-SCOPE would not need a definition, since it is mere
data to a containing DEFUN. But I would add a definition like
(defmacro in-this-scope (&rest whatever)
(declare (ignore whatever))
(error "IN-THIS-SCOPE used out of place. It must occur in a DEFUN."))
> then you could do
> (define (fcn)
> (in-this-scope (let ((a 3)))
> (do something-1)
> (in-this-scope (let ((b 7)))
> (do something-2))
>
> which would be like
> (define (fcn)
> (let ((a 3))
> (do-something)
> (let ((b 3))
> (do-something-2))))
Though visually it's hard to tell whether it's that or
(define (fcn)
(let ((a 3))
(do-something))
(let ((b 3))
(do-something-2)))
The nice thing about putting parens AROUND the thing you want bindings to
apply to is that you avoid ambiguity issues like this.
> a macro for in-this-scope would be ok, but i can't think of a way of doing
> this without changing the basic reader/parser
Yes, you could also define a prefix marker that said "the next two forms
will be an "in-this-scope form" and then a "form that needs to be put in it.
But there is ALREADY such a syntax in Lisp: the paren. ;-)
Btw, CL does come with one pre-defined situation that acts like what you
suggest, and it itself is quite controversial: LOOP. Note that we don't
have a billion little macros for FOR, COUNT, MAXIMIZING, etc. Instead LOOP
uses its body as data and rewrites itself. But though it's VERY useful
because it adds conciseness and readability to something that arguably isn't
concise or readable in many cases, it didn't make many friends for having
violated normal Lispy syntax style rules. People use it in spite of how much
they hate the syntax. Your situation is similar, except your thing is more
verbose than the alternative, and the only thing you're saving is maybe
some indentation... that's a pretty tenuous positive to trade for such a
major syntactic negative, and I predict most others will agree with me
that this is a bad trade.
JMO. YMMV.
From: Alhambra Petrofsky
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <87d73vid7c.fsf@radish.petrofsky.org>
[Cross-posting this sort of question is not prudent. My answer is for
the scheme language, so I've set followups to comp.lang.scheme]
"Masoud Pirnazar" <···········@apptek.com> writes:
> does anyone have ideas on how to implement something like this:
>
> (in-this-scope ...)
>
> for example,
> (in-this-scope let ((a 3) (b 9))) xxx
> is the same as
> (let ((a 3) (b 9)) xxx)
>
> i.e. (in-this-scope aaa bbb ...) xxx is equivalent to (aaa bbb
> ... xxx) it could be used with (let-macro ...) and other forms that
> bring in new definitions, without making the function
>
> then you could do
> (define (fcn)
> (in-this-scope (let ((a 3)))
> (do something-1)
> (in-this-scope (let ((b 7)))
> (do something-2))
>
> which would be like
> (define (fcn)
> (let ((a 3))
> (do-something)
> (let ((b 3))
> (do-something-2))))
>
> a macro for in-this-scope would be ok, but i can't think of a way of doing
> this without changing the basic reader/parser
This would have to be implemented as a feature of the form in which
the list of expressions occurs. Something like this:
(define-syntax begin+
(syntax-rules (in-this-scope)
((_ (in-this-scope foo ...) . exps) (foo ... (begin+ . exps)))
((_ exp) exp)
((_ exp . exps) (begin exp (begin+ . exps)))))
(define-syntax define+
(syntax-rules ()
((_ (var . args) . exps) (define (var . args) (begin+ . exps)))
((_ . anything-else) (define . anything-else))))
Example use:
(define+ (foo x)
(in-this-scope let* ((y (+ x x)) (z (+ y y))))
(set! z (+ z z))
(in-this-scope let-syntax ((bar (syntax-rules () ((_ form) 'form)))))
(in-this-scope let ((baz (cons (bar z) z))))
baz)
(foo 1) => (z . 8)
-al
From: Drew McDermott
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <3BC6094B.5962B4BA@yale.edu>
Masoud Pirnazar wrote:
> does anyone have ideas on how to implement something like this:
>
> (define (fcn)
> (in-this-scope (let ((a 3)))
> (do something-1)
> (in-this-scope (let ((b 7)))
> (do something-2))
>
> which would be like
> (define (fcn)
> (let ((a 3))
> (do-something)
> (let ((b 3))
> (do-something-2))))
>
> a macro for in-this-scope would be ok, but i can't think of a way of doing
> this without changing the basic reader/parser
Rather than redefine defun, and all the other constructs where 'in-this-scope'
could appear, why not write a single macro
(scope ... (in-this-scope ...) .... (in-this-scope ...) ...)
So you'd write
(defun fcn (...)
(scope
(in-this-scope (let ((a 3)))
....))
You have to indent once, for the scope itself, but after you're home free.
But if you dislike Lisp syntax so much, why not go all the way and write an
infix parser, so you could write
(defun fcn (x)
(parse
int a = 3 \;
if (a > x) return <something cruddy and un-Lisp-like>
int b = x - a \;
<even uglier stuff>))
You have to put spaces around tokens, so you can't write "a>x"; it has to be
"a > x".
There's probably a better way to handle semicolons than slashifying them.
-- Drew McDermott
From: Thomas F. Burdick
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <xcvofnd21d6.fsf@famine.OCF.Berkeley.EDU>
Drew McDermott <··············@yale.edu> writes:
> But if you dislike Lisp syntax so much, why not go all the way and write an
> infix parser, so you could write
>
> (defun fcn (x)
> (parse
> int a = 3 \;
> if (a > x) return <something cruddy and un-Lisp-like>
> int b = x - a \;
> <even uglier stuff>))
>
> You have to put spaces around tokens, so you can't write "a>x"; it has to be
> "a > x".
>
> There's probably a better way to handle semicolons than slashifying them.
Of course there is: you're enthusiastic about your new syntax, right?
So show it! Terminate your expressions with an exclamation point!
(defun foo (x)
"Ewwwww...."
(with-hairy-syntax
a = 3 !
if (a > x) x := a !
x := x - a ! )
x)
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>Of course there is: you're enthusiastic about your new syntax, right?
>So show it! Terminate your expressions with an exclamation point!
>
>(defun foo (x)
> "Ewwwww...."
> (with-hairy-syntax
> a = 3 !
> if (a > x) x := a !
> x := x - a ! )
> x)
And for those lines of code the compiler is supposed to ignore
(defun foo (x)
"Ewwwww...."
(with-hairy-syntax
a = 3 !
if (a > x) x := a !
x := x - a !
a := 0 ;-)
)
x)
From: Kent M Pitman
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <sfw669lafj5.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Drew McDermott <··············@yale.edu> writes:
> Rather than redefine defun, and all the other constructs where
> 'in-this-scope' could appear, why not write a single macro
> (scope ... (in-this-scope ...) .... (in-this-scope ...) ...)
>
> So you'd write
> (defun fcn (...)
> (scope
> (in-this-scope (let ((a 3)))
> ....))
This is an improvement, surely.
> You have to indent once, for the scope itself, but after you're home free.
>
> But if you dislike Lisp syntax so much, why not go all the way and write an
> infix parser, so you could write
>
> (defun fcn (x)
> (parse
> int a = 3 \;
> if (a > x) return <something cruddy and un-Lisp-like>
> int b = x - a \;
> <even uglier stuff>))
Let's see, how shall we do it? Oh, I know:
(defmacro dont-loop (&body loop-stuff)
`(loop repeat 1
,@loop-stuff))
(dont-loop with x = 7
for a of-type fixnum = (- x 3)
for b of-type fixnum = (- x a)
when (> a x) return 42
do (print (list a b x)))
>
> You have to put spaces around tokens, so you can't write "a>x";
> it has to be "a > x".
Or you can use the loop parsing rules. ;-)
> There's probably a better way to handle semicolons than slashifying them.
Omitting them? ;-)
From: ···@itasoftware.com
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <u1x5xa1b.fsf@itasoftware.com>
> Drew McDermott <··············@yale.edu> writes:
>
> > There's probably a better way to handle semicolons than slashifying them.
Kent M Pitman <······@world.std.com> writes:
>
> Omitting them? ;-)
You can't omit the semicolons! Everybody *knows* that semicolons are
one of the most important tokens to include in a language (followed
closely by curly braces). Why, a language without semicolons would be
virtually unreadable by a human being.
From: Erik Naggum
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <3211884571335687@naggum.net>
* ···@itasoftware.com
| You can't omit the semicolons! Everybody *knows* that semicolons are
| one of the most important tokens to include in a language (followed
| closely by curly braces). Why, a language without semicolons would be
| virtually unreadable by a human being.
So true! That is why semicolons should be used for comments that are
_only_ readable by human beings. But so much code in other languages
have all these lines with empty comments, as if saying "no comment" to
all the pressing questions of why the code is the way it is.
///
--
My hero, George W. Bush, has taught me how to deal with people. "Make no
mistake", he has said about 2500 times in the past three weeks, and those
who make mistakes now feel his infinite wrath, or was that enduring care?
From: Masoud Pirnazar
Subject: Re: an (in-this-scope...) special form to avoid excessive nesting in source code
Date:
Message-ID: <9q7clm$dab@dispatch.concentric.net>
ok, we're getting off the subject, but what the heck.
try this experiment:
take an english text (or another language),
1. remove all punctuation (big deal, it's still readable)
2. remove all spaces (surprising how you can still read it; it's like
chinese, no spaces, but more ambiguity)
3. remove all vowels (now more like arabic and hebrew, where most vowels,
which are diacritic marks, are omitted)
i got headaches reading it at first, but got used to it (either the
headaches or to reading it).
or reverse steps 3 and 2.
along another note, does anyone think that (+ 3 1 5 9 2) is as easy to read
and manipulate (cognitively) as (+ 3 (+ 1 (+ 5 (+ 9 2))))))))))))))))?
if you could make a programming language where programmers could write in
english, you'd find that most people can't write english.
<···@itasoftware.com> wrote in message ·················@itasoftware.com...
>
>
> > Drew McDermott <··············@yale.edu> writes:
> >
> > > There's probably a better way to handle semicolons than slashifying
them.
>
> Kent M Pitman <······@world.std.com> writes:
> >
> > Omitting them? ;-)
>
> You can't omit the semicolons! Everybody *knows* that semicolons are
> one of the most important tokens to include in a language (followed
> closely by curly braces). Why, a language without semicolons would be
> virtually unreadable by a human being.