Hello,

I remember reading some postings on comp.lang.scheme about some people
coming up with a dialect of Scheme that would use indentation to
replace parentheses. This grew out of some discussion on Python. I
hadn't ever used Python, so I took a look at some sample code on Peter
Norvig's webpage. That's when it hit me: it looked just like the Logo
code I had to use in UC Berkeley's CS 61A!

So I started doing some light reading on Logo. Wikipedia even
describes it as "Scheme without parentheses".

So, given suitable libraries for POSIX functionality, could Logo be
very similar to Python? Even replace it when necessary?

~Tomer

joe marshall

taltman@noshpam.lbl.government writes:

You should look at this:
http://compsoc.dur.ac.uk/whitespace/

They have dispensed with everything *but* the indentation. The code
is the clearest I've encountered.

--
~jrm

henrik motakef

taltman@noshpam.lbl.government writes:

If you are more generically interested in a "Lisp-like language
without parentheses", you could also try Dylan.

marco antoniotti

INTERCAL is dead.

Cheers

--
Marco

bh

taltman@noshpam.lbl.government writes:


Logo (as you should remember from 61A!) is different from most modern Lisp
dialects (including Scheme) in one important way: it's dynamically scoped.
So "Scheme without parentheses" is only fuzzily true; it would be fairer to
say "traditional Lisp without parentheses."

Whether the scope rules matter to you depends on what you're trying to do. I
don't want to start a dispute about which is better; personally, I find uses
for both Scheme and Logo. I'd certainly choose Scheme for a large real-world
programming project, but I prefer Logo for teaching young kids. For little
quick-and-dirty projects, I've used both, generally deciding on some basis
other than the scope rules; for example, if the problem involves tearing words
apart into letters, I use Logo, but if the problem requires bignums, I use
Scheme.

Python's scope rules, iirc, are complicated and kinda ugly, neither fish nor
fowl. It has other strengths, such as the use of sets as a primitive data
type.

Note that I've been talking about semantics, not syntax. If the Python
feature you're trying to emulate is the use of indentation to delimit program
blocks, Logo doesn't do that. Instead of program blocks, Logo uses
instruction lists, as Lisp does in the EVAL procedure. Logo uses square
brackets, rather than parentheses, to delimit literal lists, but that isn't
much of a difference. The "without parentheses" aspect of Logo is that when a
procedure takes a fixed number of arguments, you don't have to enclose the
procedure call in parentheses.

In some Logo dialects, a procedure call must all be within a single line (and
there is some sort of continuation-character mechanism to allow multi-line
"lines"); in other dialects, newline is exactly equivalent to space. I think
this all feels pretty different from the way whitespace is used in Python.

P.S. Making indentation significant is *not* my favorite Python feature.
I've had too many experiences moving (C) code from one machine to another, and
discovering that the GUI on the new machine has a different idea of how many
spaces there are in a tab. In C (and Scheme and Logo) that doesn't matter
except for making the program look ugly, but in Python it would matter.

als

In this case, bring on the proper necromancer. How about an INTERCAL
compiler in Common Lisp (to kick this back to topic)?

But ITYM the Whitespace programming language.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

david golden

There is/was Sugar. It's a pretty small change to scheme syntax, really -
everything's still prefix, it's just indentation and a "group" keyword take
the place of parens.

http://redhog.org/Projects/Programming/Current/Sugar/

define
fac x
if
= x 0
1
* x
fac
- x 1

joe marshall

bh@cs.berkeley.edu (Brian Harvey) writes:

There is another important difference: it is *extremely* focused on
imperative programmming. Yes, you *can* write in a functional style
with Logo, but it is extraordinarily difficult to write any sort of
graphics programs in Logo this way. This is the primary reason I
don't teach it to my kids. (dynamic scope is the second)

--
~jrm

michele.simionato

Often I don't have a machine with emacs installed and I cannot
install it or I don't want to install it. For this reason, I have thought
of a number of ways to contain the number of parens in Scheme, just to
be able to use poor man editors.
My first implemented solution was a preprocessor to convert indentation
in parentheses (there are many of those solutions already available in
the literature). However, I was unsatisfied with that solution, because:

1) an external tool (the proprecessor) was needed;
2) I couldn't easily mix normal code and indented code;
3) even significant identation needs some support from the editor.

It is easier to write indented code in notepad than parenthesized
code: but it not THAT easier, especially if you have to reindent
by hand entire blocks of code. Also, significant indentation has
his own drawbacks (try to cut&paste indented code from an e-mail
message or a web page).

So, here comes my second solution: a parenthesis-supplier macro.
This solution avoids all the drawbacks listed before. Let me give an example:
(>>> ; valid Scheme code with less parens

; the evergreen factorial
(define (fac x) :
if (= x 0) 1 : * x : fac : - x 1)

(print : fac 10) )
The ">>>" macro converts the previous code to

(define (fac x)
(if (= x 0) 1 ( * x ( fac ( - x 1)))))

(print (fac 10))

The rules is: at each colon, open a parens; all the parens will be
automatically closed at the end of the expression. So, I don't need
to count how many parens to close at the end of the factorial.

Each colon saves two parens, so the first version of the script
save 10 parens, and the total number of parens decreases from
18 to 8. Quite a large saving. Statistics on my code using
this trick says that I am saving parens even with respect to
Python! And this is pure valid Scheme code. So it is not true
that you necessarily needs lots of parens. The colon notation
needs some time to get accustomed, but it is no more difficult
to read than the parenthezed version, and it is much easier to
write. I can mix colons and regular parens as I wish.
Plus, it is easy to restore all the parens, if I want to.

So, I am quite happy with this trick. Here is the implementation:
it requires "fold-right" found in srfi-1; I tested it with Chicken,
my Scheme implementation of choice :-)

(require 'srfi-1) ; needs fold-right
(define (colons->parens ls)

(define (consumer el ls) (cond
((and (list? el) (not (null? el))) (cons (colons->parens el) ls))
((eq? el ' (list ls))
(else (cons el ls))))

(fold-right consumer '() ls))

(define-macro (>>> . code-list)
(colons->parens (cons 'begin code-list)))

jacek generowicz

Joe Marshall <prunesquallor@comcast.net> writes:

So, what _did_ you teach your kids ?

What experiencens have you (plural) had with teaching programming to
kids? What to look out for? What to avoid? When to start? etc.