I need to teach some Perl folk Lisp. Last time I tried that, they got
lost in the parens and couldn't see the code. So I was thinking about
defining an alternate, more Perl/C-like syntax:
sub factorial (n) {
sub helper (n,acc) {
case (n) {
is 0: acc;
else: helper(n-1, n*acc);
}
}
helper(n,1);
}
transforms to:
(defun factorial (n)
(labels
((helper (n acc)
(case n
(0 acc)
(t (helper (- n 1) (* n acc))))))
(helper n 1)))
Has anybody tried this? I know that there have been alternate
syntaxes defined for Lisp, but I don't know if any of them have been
used specifically for teaching, with the intention of teaching sexp
notation later.
What kind of success have people had doing this?
Cheers,
joelh
Joel Ray Holveck <·····@piquan.org> writes:
> I need to teach some Perl folk Lisp. Last time I tried that, they got
> lost in the parens and couldn't see the code.
That's funny. In my experience students get along with the
parentheses extremely well. I just tell them
(operation arg-1 arg-2 etc)
and they get it. They start programming interesting stuff after just
one hour of such teaching. Of course, it's important to tell them not
to program in an inappropriate editor.
> So I was thinking about defining an alternate, more Perl/C-like
> syntax: [...]
So your students learn your own little language. That's probably good
for you ego, but your students have no second sources of information
to resort to (for more advanced or more basic explanations and
examples than you will be able to give in your class). That's a
serious drawback.
>> I need to teach some Perl folk Lisp. Last time I tried that, they got
>> lost in the parens and couldn't see the code.
> That's funny. In my experience students get along with the
> parentheses extremely well. I just tell them
> (operation arg-1 arg-2 etc)
> and they get it.
I started that way, and some of my students lost track when I
introduced COND. Even DEFUN doesn't follow that syntax.
>> So I was thinking about defining an alternate, more Perl/C-like
>> syntax: [...]
> So your students learn your own little language. That's probably good
> for you ego, but your students have no second sources of information
> to resort to (for more advanced or more basic explanations and
> examples than you will be able to give in your class). That's a
> serious drawback.
An excellent point, thank you!
joelh
Joel Ray Holveck <·····@piquan.org> wrote in message news:<··············@thor.piquan.org>...
> I started that way, and some of my students lost track when I
> introduced COND. Even DEFUN doesn't follow that syntax.
>
yes, they do. for instance:
(DEFUN thing args [form ...])
Everything in Lisp has exactly the same form, it's just that the
evaluation rules for some of the arguments are funny.
--tim
Joel Ray Holveck <·····@piquan.org> writes:
> I need to teach some Perl folk Lisp. Last time I tried that, they got
> lost in the parens and couldn't see the code. So I was thinking about
> defining an alternate, more Perl/C-like syntax:
>
> sub factorial (n) {
> sub helper (n,acc) {
> case (n) {
> is 0: acc;
> else: helper(n-1, n*acc);
> }
> }
> helper(n,1);
> }
>
> transforms to:
>
> (defun factorial (n)
> (labels
> ((helper (n acc)
> (case n
> (0 acc)
> (t (helper (- n 1) (* n acc))))))
> (helper n 1)))
>
> Has anybody tried this? I know that there have been alternate
> syntaxes defined for Lisp, but I don't know if any of them have been
> used specifically for teaching, with the intention of teaching sexp
> notation later.
>
> What kind of success have people had doing this?
It's above me! Why should one try to write perl code in lisp when you
can as well write assembler code:
(defun delete-from-length-asm (str index delen)
(let (r1 r2 r3 r4 r5)
(setq r1 index)
(if (>= r1 0)
(go :l1))
(setq index 0)
(go :l2)
:l1
(setq r1 (length str))
(setq r2 index)
(if (> r1 r2)
(go :l3))
(setq r1 str)
(go :l99)
:l3
:l2
(setq r1 (length str))
(setq r2 index)
(setq r3 delen)
(setq r2 (+ r2 r3))
(if (>= r1 r2)
(go :l4))
(setq r1 (length str))
(setq r2 index)
(setq r1 (- r1 r2))
(setq delen r1)
:l4
(setq r1 index)
(setq r2 delen)
(setq r1 (- r1 r2))
(setq r2 (length str))
(setq r5 (aref str r2))
(setf (aref str r1) r5)
(setq r1 str)
;l99
));;delete-from-length-asm
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Joel Ray Holveck <·····@piquan.org> writes:
> I need to teach some Perl folk Lisp. Last time I tried that, they got
> lost in the parens and couldn't see the code. So I was thinking about
> defining an alternate, more Perl/C-like syntax:
>
> sub factorial (n) {
> sub helper (n,acc) {
> case (n) {
> is 0: acc;
> else: helper(n-1, n*acc);
> }
> }
> helper(n,1);
> }
So, how're you going to teach them about DEFMACRO?
Seriously, Lisp's syntax is one of its most beautiful
and well-designed feature. Mapping it onto Perl doesn't
seem like a win.
Why are you teaching these Perlers lisp? Do they have
a choice? Are they willing to learn it, or are they
being forced by circumstances?
> What kind of success have people had doing this?
Little to none is what I would expect.
> So, how're you going to teach them about DEFMACRO?
I planned to teach them sexps once they were comfortable with some
basic concepts.
> Why are you teaching these Perlers lisp? Do they have
> a choice? Are they willing to learn it, or are they
> being forced by circumstances?
A little from column A, a little from column B.
At work, I have a big project that's vital to the department, and
written in Lisp. I'm the only one who knows Lisp. So one guy has to
learn it.
The others are friends who want to learn just for the sake of
learning.
Thanks,
joelh
Joel Ray Holveck <·····@piquan.org> writes:
> At work, I have a big project that's vital to the department, and
> written in Lisp. I'm the only one who knows Lisp. So one guy has to
> learn it.
>
> The others are friends who want to learn just for the sake of
> learning.
OK, that's not too bad. At my job, I was hired and chose lisp,
and built a team around it. Of the pre-existing engineers, one
decided to bite the bullet and learn lisp, the other didn't.
He learned it very well indeed (but he's a _very_ bright young man).
I don't think any Perl or bizarre syntax subterfuges are necessary,
though. Just use the Yoda line: "You must _unlearn_ what you have learnt."
You really have to hook them by making them believe that there's another
entire world of software ideas they've never heard of.
Good luck!
In article <··············@thor.piquan.org>,
Joel Ray Holveck <·····@piquan.org> wrote:
> I need to teach some Perl folk Lisp. Last time I tried that, they got
> lost in the parens and couldn't see the code. So I was thinking about
> defining an alternate, more Perl/C-like syntax:
>
> sub factorial (n) {
> sub helper (n,acc) {
> case (n) {
> is 0: acc;
> else: helper(n-1, n*acc);
> }
> }
> helper(n,1);
> }
This is perfectly good Dylan:
---------------------------------
module: fact
define method factorial(n)
local method helper(n,acc)
select (n)
0 => acc;
otherwise => helper(n - 1, n * acc);
end;
end helper;
helper(n,1);
end factorial;
begin
let n = 10;
format-out("Factorial of %d is %d\n",
n, factorial(n));
end
----------------------------------
Dylan is a different language than Common Lisp, and differs considerably
in places, but they have most of the same features and can often be
trivially transliterated into each other.
-- Bruce
> Joel Ray Holveck <·····@piquan.org> wrote:
>
>
>>I need to teach some Perl folk Lisp. Last time I tried that, they got
>>lost in the parens and couldn't see the code.
A week ago you asked:
>> So if you had an M-exp reader, and knew how it works, you'd still
>> adamantly write in S-exps? Not just write in them because you're
>> used to them, but *adamantly*[1] write in them?
So what is /your/ answer to that question?
The correct answer is: yes, with a parens-aware editor I can edit two or
three times faster than without. They are an advantage, and me and my
monkeys need all the help we can get.
and parentheses should be taught that way, as an advantage.
My guess is your students would have fewer problems with parentheses if
you yourself had more enthusiasm for them.
kt
Kenny Tilton wrote:
> The correct answer is: yes, with a parens-aware editor I can edit two or
> three times faster than without. They are an advantage, and me and my
> monkeys need all the help we can get.
>
> and parentheses should be taught that way, as an advantage.
>
> My guess is your students would have fewer problems with parentheses if
> you yourself had more enthusiasm for them.
I'm with Kenny on this one. As a Lisp newbie (3 months or so now), my
experience is that you just have to get over them, suck it up, and forge
ahead. Once you get used to them (took me about a week), they are a huge
advantage. Use emacs as your editor and you're all set. You can move around
by sexprs, cut and paste sexprs, and basically do just about anything on a
full sexpr level. That's a huge editing win even versus line-oriented
languages like C/C++/Java, etc.
Yes, I wouldn't try to write Lisp in Windows Notepad, but then again, there
isn't much I would try to write in Windows Notepad.
In short, 45+ years of Lisp users can't be wrong... ;-)
--
Dave Roberts
·············@re-move.droberts.com
> A week ago you asked:
>>> So if you had an M-exp reader, and knew how it works, you'd still
>>> adamantly write in S-exps? Not just write in them because you're
>>> used to them, but *adamantly*[1] write in them?
> So what is /your/ answer to that question?
I would continue to write in sexps because I'm used to them. If I had
first learned on M-exps, I probably would continue to use M-exps if
somebody offered me a sexp reader.
> My guess is your students would have fewer problems with parentheses
> if you yourself had more enthusiasm for them.
I'm perfectly comfortable in parens, but don't see them as an
Amazingly Great Thing.
Now, I do think that having sexps as part of the language is an
Amazingly Great Thing, because it lets us use defmacro and other
source transformations. But I think that sexps, m-exps, Dylan syntax,
my hypothetical syntax, etc, don't in and of themselves make things
easier to use. It's all just isomorphic syntaxes.
FWIW, I do tend to use C-M-u and the like even in C and Perl.
joelh
> The correct answer is: yes, with a parens-aware editor I can edit two
> or three times faster than without. They are an advantage, and me and
> my monkeys need all the help we can get.
>
> and parentheses should be taught that way, as an advantage.
Maybe I'm doing something wrong in my daily editing. I usually don't
see parens as a syntactic advantage in editing. (Exception: I can
skip over (+ foo (* bar baz)) in one keystroke, but not foo+bar*baz.)
I mostly move around code-- Lisp, C, Perl, whatever-- using C-M-u
(backward-up-list), C-M-d (down-list), and C-M-f / C-M-b (forward-sexp
/ backward-sexp) [1]. M-. (edit-definitions-lisp/find-tag) and C-s
(isearch-forward) are handy when you need 'em. I tend to be a bit
more sparing with C-n/C-p/C-f/C-b than most people I see writing code,
preferring to use the ones I mentioned.
I find myself using these fairly similarly in all languages. I'll
skip over chained if/elsif/else clauses (which I usually mark in
braces) using C-M-f, just as I would clauses of a cond.
Is this about what you do, or do you have other techniques that work
better?
Thanks,
joelh
[1] I don't ever use C-M-n or C-M-p because I find them to be slightly
less useful than C-M-f or C-M-d; I have to think about whether I'm
skipping over an atom or a list. Other commands, like C-M-a, I use
rarely enough that I tend to use a substitute (such as C-u C-u C-M-u)
instead.
Joel Ray Holveck wrote:
>>The correct answer is: yes, with a parens-aware editor I can edit two
>>or three times faster than without. They are an advantage, and me and
>>my monkeys need all the help we can get.
>>
>>and parentheses should be taught that way, as an advantage.
>
>
> Maybe I'm doing something wrong in my daily editing. I usually don't
> see parens as a syntactic advantage in editing.
It is well we have identified this extreme mileage variation so early in
the chat. :)
> I mostly move around code-- Lisp, C, Perl, whatever-- using C-M-u
> (backward-up-list), C-M-d (down-list), and C-M-f / C-M-b (forward-sexp
> / backward-sexp)
I never learned those. home. end. tab. page up/down. and the mouse. i
usually have a hand on the mouse, with the middle button set to
double-click so I can select a form in one go. c-k delete to end of
line, c-w, m-w, and c-y, not that those are relevant to sexprs. but the
key is being able to select a parenthesized form small or large with one
click (or one keychord I suppose for keyboard maestros).
the big point is that sexprs textually unify what is semantically
unified: a function name /and/ the arguments passed. etc etc etc.
Without sexprs, my text is organized differently than the semantics, and
suddenly I am doing pin-point (hopefully) drags to select what a Lisp
editor can figure out for itself, even when it is a huge wadge of code
running off the screen.
AllegroCL has a special click (but brought over from Lisp machines?
anyway...). c-click effectively in one go copies the clicked form and
pastes it. so it is a pure insert or a replace if any text is selected.
I use it incessantly. A classic is a refactoring where a nested form
ends up being all I need: middle-click the outer form, m-click the inner
form. fini.
or I write some code and start out tentatively;
(let ((x (big-mo fo (nested form))))
....stuff...
(finally-just-use x :once t))
ctr-click second "x"
m-click big-mo
ctr-click (x (big-mo...))
del
Note that in some cases there is a lot of real estate crossed by that
m-click transport, so I am really painting my code from on high, not
crawling over it like an anthill.
And when the dust settles, c-shift-p, thank you very much. But I also
like to machine gun down-tab pairs and watch the code zipper into place
to see if I got lost splashing the paint around.
kt
Kenny Tilton wrote:
>
> and parentheses should be taught that way, as an advantage.
To be honest, there's also a drawback: as soon as you get
accustomed to use Lisp syntax, you feel like an idiot when
using an ugly mess of contradictory conventions.
Joel Ray Holveck <·····@piquan.org> writes:
> I need to teach some Perl folk Lisp. Last time I tried that, they got
> lost in the parens and couldn't see the code. So I was thinking about
> defining an alternate, more Perl/C-like syntax:
Maybe you could introduce S-expressions like this (let's not worry about
what the first program means):
1. Conceptually, drop the girly-man operators and special notation,
and write _everything_ except constants and variables as function
calls ...
fac(x, acc) =
if( =(x,0),
acc,
helper(-(n,1), *(n, acc))
)
2. ... but with no commas between arguments and the function name
_inside_ the parentheses:
(defun fac (x acc)
(if (= x 0)
acc
(helper (- n 1) (* n acc))))
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin