BEGIN 
Author Message
 BEGIN

   I don't like the provided 'begin', though - it's messy (really two forms),
   and counterintuitive (no corresponding 'end').  Why did 'sequence' ever
   change into 'begin'?  What about 'block' or some such name?

I hate the name, myself. I much preferred BLOCK. I also think internal
define's are the single ugliest thing about the language.
    -Olin



Fri, 18 Oct 1996 11:13:20 GMT  
 BEGIN
|>    I don't like the provided 'begin', though - it's messy (really two forms),
|>    and counterintuitive (no corresponding 'end').  Why did 'sequence' ever
|>    change into 'begin'?  What about 'block' or some such name?
|>
|> I hate the name, myself. I much preferred BLOCK. I also think internal
|> define's are the single ugliest thing about the language.
|>     -Olin

internal defines, ugly?! Internal defines are an extremly useful, portable way
to tell optimizing compilers that certain procedures will never be redefined.
Even more, a sequence of "local" defines behaves almost identical to a
sequence of top-level defines, so I believe it should look almost identical
as well.

  What I'm wondering in this BEGIN discussion is if you really ever need
macros that create several definitions. In fact, I'm happily programming in
Scheme for some time now and the only thing I've used macros for is
procedure inlining. I suspect that simply because the R3RS defined the derived
expression types using rewrite rules, everybody believed they would have to be
implemented via rewrite rules, and if you've got rewrite rules already, why
not permit the user to make up more of them?
  Seriously, does anybody actually need macros? There seems to be lots of code
that uses macros, but what for ?!

- axel



Mon, 21 Oct 1996 01:04:53 GMT  
 BEGIN

   Even more, a sequence of "local" defines behaves almost identical to a
                                                    ------
   sequence of top-level defines [...]

Vis a vis my previous message, why is it `almost identical' and not
`identical'?
        Jeff



Mon, 21 Oct 1996 05:16:16 GMT  
 BEGIN

Quote:

>   I hated internal defines when I first saw them, then I changed my
> mind and had brief flirtation with them, but after a while of using
> them I decided that they are truly ugly and eliminated them from all
> my code.

I guess they are mostly here for macros. You dont' write them
directly, but they can be introduced by macro expansion.
But that's only a guess !

Quote:
>    (letrec (((f n) ...)                                    [1]
>             ((g n) ...))
>      ...)

>    (fletrec ((f (n) ...)                                   [2]
>              (g (n) ...))
>      ...)

As you say [1] clashes with "pattern matching extensions" or "multiple
values" and [2] doesn't fit the traditional define syntax.

So, what about [21]:

        (fletrec (((f n) ...)
                  ((g m) ...))
           ...)

I personally don't like "fletrec" cause it's too "a single s is more
efficient to type" and I prefer readability. I'd suggest "funlet" or
"letfun" and "funrec" or "recfun" (or maybe "letrecfun" or
"funletrec").

        Stefan



Tue, 22 Oct 1996 16:20:08 GMT  
 BEGIN

|> [...]
|>   The point of this is, I think, that internal defines fill some basic
|> syntactic gap in the language.  At the toplevel we have this neat
|> syntax for defining procedures, e.g.,
|>
|>   (define (f x y z ...) ...)
|>
|> but we can't do this for nested procedures, instead we have to use
|>
|>   (let ((f (lambda (x y z ...) ...))) ...)
|>
|> which isn't half as nice.

I always felt that the syntax for lambda expressions has too much overhead,
compared for example to code blocks in Smalltalk (I don't know much about
smalltalk, I just remember seeing some code once). The annoying thing is having
to write 'lambda' every time. Maybe if we use some other kind of braces for
this purpose?

[ <args> | <body> ]

instead of

(lambda (<args>) <body>)

This could be a shortcut like unquote or unquote-splicing. For example:

(map [x | (+ x 1)] '(1 2 3))

(letrec ((f [n | ...])
         (g [n | ...]))
   ...)

(define (reverse l)
  (letrec
    ((iter [rest accu
           | (if (null? rest)
                 accu
                 (iter (cdr rest) (cons (car rest) accu)))]))
    (iter l '())))

Note that "thunks" would look extremely simple:

(execute-ten-times [| (display "Hello!")])

--axel



Tue, 22 Oct 1996 22:32:34 GMT  
 BEGIN

Quote:

>I always felt that the syntax for lambda expressions has too much overhead,
>compared for example to code blocks in smalltalk (I don't know much about
>smalltalk, I just remember seeing some code once). The annoying thing is having
>to write 'lambda' every time. Maybe if we use some other kind of braces for
>this purpose?
>[ <args> | <body> ]
>instead of
>(lambda (<args>) <body>)

If 'lambda' is too big for your taste, define an alias '&'.  (Backslash would
be better, since it looks more like a lambda character, but it's already
taken.)
For example:

(repeat 10 (& () (print 'hello)))



Wed, 23 Oct 1996 02:01:08 GMT  
 BEGIN

Axel> internal defines, ugly?! Internal defines are an extremly
Axel> useful, portable way to tell optimizing compilers that certain
Axel> procedures will never be redefined.

Really?  Which compilers assume this?  If any compilers do assume that
variables defined by internal defines are constant then they are
wrong.  Besides you don't need a mechanism to do this, a compiler can
discover which local variables are assigned to by examining the
programs text (just look for set! forms).

Axel> Even more, a sequence of "local" defines behaves almost
Axel> identical to a sequence of top-level defines, so I believe it
Axel> should look almost identical as well.

The operative word here is almost.  A sequence of internal defines is
"completely equivalent"* to a letrec, but a sequence of toplevel
defines is more like a mixture of let* and letrec.  This is the thing
that put me off internal defines, I tried to use them like toplevel
defines and they didn't quite work.

Hugh

* The R4RS's words.
--
Hugh Emberson              | Mere knowledge is not enough to fully utilize the

---------------------------+------------- Per Abrahamsen in alt.religion.emacs



Thu, 24 Oct 1996 01:27:48 GMT  
 BEGIN

Olin> I hate the name, myself. I much preferred BLOCK. I also think internal
Olin> define's are the single ugliest thing about the language.
Olin>     -Olin

  I hated internal defines when I first saw them, then I changed my
mind and had brief flirtation with them, but after a while of using
them I decided that they are truly ugly and eliminated them from all
my code.

  The point of this is, I think, that internal defines fill some basic
syntactic gap in the language.  At the toplevel we have this neat
syntax for defining procedures, e.g.,

        (define (f x y z ...) ...)

but we can't do this for nested procedures, instead we have to use

        (let ((f (lambda (x y z ...) ...))) ...)

which isn't half as nice.  What we need is some syntax for defining
procedures inside let expressions which is as nice to use as define at
toplevel, then we will be able to eliminate those hideous internal
defines once and for all.  

  Unfortunately, I can't think of a suitable, unambiguous, syntax.  We
could use

        (letrec (((f n) ...)                                    [1]
                 ((g n) ...))
          ...)

which is OK, but it looks like one of those multiple value return
syntaxes.  We could use a special version of let for declaring
procedures like Common Lisp (this is my schemified version)

        (fletrec ((f (n) ...)                                   [2]
                  (g (n) ...))
          ...)

which looks pretty good, but it clashes with the syntax we use with
define (we'd have to introduce a defun from to be consistent), and at
a more basic level, it clashes with the ``procedures are first class
citizens'' idea.

Are there any other syntaxes we could use?  Assuming there aren't, I
guess that [1] is the best.

I think that a language with such nice semantics should have a nice
syntax too.  I think that this is the one remaining problem with
Schemes syntax.

Hugh
--
Hugh Emberson              | Mere knowledge is not enough to fully utilize the

---------------------------+------------- Per Abrahamsen in alt.religion.emacs



Wed, 23 Oct 1996 01:02:35 GMT  
 BEGIN

Stefan> So, what about [21]:

Stefan>      (fletrec (((f n) ...)
Stefan>                ((g m) ...))
Stefan>         ...)

Stefan> I personally don't like "fletrec" cause it's too "a single s is more
Stefan> efficient to type" and I prefer readability. I'd suggest "funlet" or
Stefan> "letfun" and "funrec" or "recfun" (or maybe "letrecfun" or
Stefan> "funletrec").

That's a nice syntactic compromise, but it still clashes with the
``procedures are first class citizens'' idea which is central to
Scheme.  We have one special form for declaring variables bound to
procedures and another for declaring variables bound to other values.
This is OK for Common Lisp, where procedures and data are treated
differently.  But it clashes badly with Scheme.

I think I'll write a macro to implement [21] and see what it looks
like.  Maybe I'll even use Hygienic macros.

Hugh
--
Hugh Emberson              | Mere knowledge is not enough to fully utilize the

---------------------------+------------- Per Abrahamsen in alt.religion.emacs



Fri, 25 Oct 1996 00:52:16 GMT  
 BEGIN

Quote:

> That's a nice syntactic compromise, but it still clashes with the
> ``procedures are first class citizens'' idea which is central to
> Scheme.  We have one special form for declaring variables bound to
> procedures and another for declaring variables bound to other values.
> This is OK for Common Lisp, where procedures and data are treated
> differently.  But it clashes badly with Scheme.

Not much more than the difference between

        (define hello 1)
and
        (define (fn a) foutaise)

It's already accepted in the scheme syntax that some sugar is
appreciable for writing functions.
Actually I personally would prefer 'defun' instead of 'define' for
the special case of the definition of a function. This would avoid the
overloading of define and clashes with a pattern-matching extension.
(and it would make a 'defclause' or 'defrel' very natural for logic extensions)

        Stefan



Thu, 24 Oct 1996 23:48:46 GMT  
 
 [ 59 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. PyKyra 0.1.0 the "Begin in the beginning, the King said" release

2. Which book should I begin with?

3. Beginning to Programm Assembler on Mainframes

4. Beginning with SmallTalk

5. "Beginning J. Second edition

6. ST - The Game Begins

7. Beginning Smalltalk

8. Inserting text at the beginning of a line

9. Nested Brackets Begin { ?

10. whitespace at beginning of second line

11. Filter by beginning of word

12. how to insert character at the beginning of each line in a file

 

 
Powered by phpBB® Forum Software