On Wed, 10 Jan 2024 22:45:37 +0100, Axel Reichert wrote:

Emacs is old, AWK is old, Unix is old.
Many of the good tools are old ...

Only the ones that people still remember, because they are still in common
use.

And also because their modern incarnations are quite different from how
they were in the early days.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Wed, 10 Jan 2024 22:45:37 +0100, Axel Reichert wrote:

Emacs is old, AWK is old, Unix is old.
Many of the good tools are old ...

Only the ones that people still remember, because they are still in common use.

(remove-if-not #'time-resistant (list tool-1 tool-2 ...))

And also because their modern incarnations are quite different from
how they were in the early days.

(mapcar #'refinement (list lindy-tool-1 lindy-tool-2 ...))

(-;

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 10 Jan 2024 17:57:13 -0500, George Neuner wrote:

... I'm not aware
of any Lisp that comes with its own GUI builder. Certainly you can use
FFI and a widget library ...

Another thing is that GUI toolkits define their own event loop. You can
hook into this with callbacks, but the fun way to do things now is via coroutines (async/await). Scheme can implement these with continuation- passing; but this is not a feature of Common Lisp.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axel Reichert <mail@axel-reichert.de> writes:

Julieta Shem <jshem@yaxenu.org> writes:

Axel Reichert <mail@axel-reichert.de> writes:

which brings me back to your original question: Since Guile is
advertised with its POSIX capabilities, I expect you could find a
better/more familiar technique there.

But that is just guessing and gut feeling, not based on any research.

Relative to my desires that's good intuition. I've been looking for a
Lisp as a medium of expression and Racket does appear to be the most
sophisticated one.

Sounds familiar. Some years back I was torn between (Steel Bank) Common
Lisp, Clojure and Racket.

That's where I am right now. I'm all for studying Racket and Clojure,
but meanwhile I'm sticking to Common Lisp. I never fell in love with a language so quickly. These new languages may be marvelous in every
single way, but like Alan Perlis would say

``I think that it’s extraordinarily important that we in computer
science keep fun in computing. [...]'' -- Alan J. Perlis (SICP, before
the table of contents.)

From an aesthetic/minimalistic point of view, I prefer
Lisp-1s/Schemes, but SBCL is just an awesome interactive experience in
Emacs with SLIME and really fast.

Maybe that's it. Really fast. Maybe that's a big thing for the fun of
it. Trivial mistakes beginners make are reported with a lot of clarity
by SBCL. I think I've never seen a more clarifying compiler ever in my
life.

Clojure feels more modern (but I am allergic against anything related
to Java) and Racket powerful (but somehow not pragmatic).

It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
for Racket. Maybe I'm too stupid for Racket.

Common Lisp seems more down to earth, but also baroque (its age
shows).

I'd be careful here. Maybe Common Lisp is still future in various
respects. For example, when it comes to fun --- it's my top first pick.
Can't say what it is, but I'm having a lot of fun with it.

seeing how much fun I was having just considering Common Lisp I did
think of Guile precisely because of the GNU Guix connection.

I somewhere read that Guile is the most Common-Lisp-like of the Scheme implementations (if you ask for it, I will try to dig up the link).

Dig it up! Let's read it and discuss it. You're invited. :-)

From my above paragraph, you can imagine that this is intriguing for
me. Especially having a reasonably fast general purpose language that purportedly integrates well with everything POSIX or C (I do not speak
C),

I think you would like to speak C. It's comforting to know what if
things ever get lower level, you'd be at home. For instance, there's
this new library that nobody created the bindings in Common Lisp or
whatever; you can do it. It's a simple thing at least for an emergency.
C is /simple/ language; that's its best feature.

can be used to configure (I should rather say "determine") the setup
of an operating system (Guix SD)

What's the SD in Guix SD? Software distribution?

and, with this OS, also for Emacs (since Guix SD has Guile Emacs,
which otherwise is said to be quite an endeavour to build/install). I
really like to reduce the number of tools in my box, provided they are powerful and I am willing to learn them deeply.

Same here. I like keep the box small and I do choose tools that I can
carry with me for a life time. That's another thing about Common Lisp
that feels very good --- you find papers and books that are ``old'' and
they describe things that are still exactly like they said. That's not
even true of C, say. C has been updated to do wild things, but gladly
we can still find old compilers and even ask the new ones to behave like
the old ones. Here's a Unix counterexample:

--8<---------------cut here---------------start------------->8---
errno

Kernel designers often add system-specific macros to
errno.h. Workaround: in files that include errno.h, avoid all macros
beginning with the letter E. Recent Linux distributions (recent
versions of glibc) refuse to compile programs that declare extern int
errno without including errno.h. This is a bug, as discussed
below. Correct behavior (all other C libraries: BSD, Solaris, etc.) is
to accept extern int errno whether or not errno.h is included. The
workaround for this Linux bug is to include errno.h everywhere, for
example by compiling with gcc -include /usr/include/errno.h.

Further comments on the Linux bug: When this change was introduced, it
was a clear and flagrant violation of IEEE Std 1003.1-1990 (POSIX),
which specifies the correct declaration to be extern int errno, nothing
more, nothing less. When Paul Wanish formally requested in 2001 that
IEEE issue an "interpretation" of IEEE Std 1003.1-1990 as meaning
something other than what it says, IEEE refused:

IEEE Std 1003.1-1990 specifies that extern int errno; is the correct declaration for errno. This is not a shorthand for a different meaning.
The glibc authors' excuse for violating IEEE Std 1003.1-1990 (and for
loudly demanding changes in subsequent standards) is that threaded
programs need a variable errno address. This excuse doesn't stand up to
even the slightest examination. Yes, threaded programs need to include
errno.h, but it's trivial to keep extern int errno working for all the non-threaded programs. The C library simply defines an int errno and has
its address as the initial value for the thread errno pointer.

Source:
https://cr.yp.to/docs/unixport.html
--8<---------------cut here---------------end--------------->8---

reading Common Lisp documentation I felt like a computing historian.

[...]

I do enjoy the history of computing quite a lot and it does feel good
to actually use tools older than the current ones that actually feels
/quite/ superior

Sure, and again, sounds familiar. Emacs is old, AWK is old, Unix is
old. Many of the good tools are old, it is called

https://en.wikipedia.org/wiki/Lindy_effect

Learn them early, try to master them until late in your life. (This
makes sense only for both powerful and versatile tools.)

Thanks for the name of the effect.

Let's end with something that makes a lot of sense to me.

--8<---------------cut here---------------start------------->8---
``The idea that new code is better than old is patently absurd. Old
code has been used. It has been tested. Lots of bugs have been found,
and they’ve been fixed. There’s nothing wrong with it. It doesn’t
acquire bugs just by sitting around on your hard drive. Au contraire,
baby! Is software supposed to be like an old Dodge Dart, that rusts
just sitting in the garage? Is software like a teddy bear that’s kind
of gross if it’s not made out of all new material?''
-- Joel Spolsky, 2000.

Source:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i --8<---------------cut here---------------end--------------->8---

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julieta Shem <jshem@yaxenu.org> writes:

Axel Reichert <mail@axel-reichert.de> writes:

I somewhere read that Guile is the most Common-Lisp-like of the
Scheme implementations (if you ask for it, I will try to dig up the
link).

Dig it up! Let's read it and discuss it. You're invited. :-)

https://ane.iki.fi/2020/10/05/between-two-lisps.html

Somewhat more biased, and, strictly speaking, off-topic here:

https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations

I think you would like to speak C.

Sure. Not only because there is an awful lot of open source software
written in it, but also due its enormous historical importance.

https://www.buildyourownlisp.com/

(Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...

What's the SD in Guix SD? Software distribution?

Ah, sorry, using the old name, nowadays it is just Guix System (the OS)
versus Guix, the package manager.

I like keep the box small and I do choose tools that I can carry with
me for a life time. That's another thing about Common Lisp that feels
very good --- you find papers and books that are ``old'' and they
describe things that are still exactly like they said.

Yes! When I searched around about the various Schemes, I became already slightly annoyed: Which RxRSs are supported, which SRFIs are included,
etc.

It doesn’t acquire bugs just by sitting around on your hard drive.

Non-perishable ...

Ideas rock.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

George Neuner <gneuner2@comcast.net> writes:

Question is whether you want to write GUI programs. Then Armed Bear
Common Lisp, Clojure or Racket have the edge ... Armed Bear and
Clojure can use Java-based GUI builders and libraries, and Racket has
its own builder and libraries.

Good point, but I am not affected, no GUI ambitions here.

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axel Reichert <mail@axel-reichert.de> writes:

George Neuner <gneuner2@comcast.net> writes:

Question is whether you want to write GUI programs. Then Armed Bear
Common Lisp, Clojure or Racket have the edge ... Armed Bear and
Clojure can use Java-based GUI builders and libraries, and Racket has
its own builder and libraries.

Good point, but I am not affected, no GUI ambitions here.

Nor here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

And also because their modern incarnations are quite different from how
they were in the early days.

I'm just following my sentimentality when choosing a LISP dialect.
In other words, it has to be as similar as possible to the LISP
I used to write simple functions for symbolic differentiation
on my Pet 2001 when I was young. Something like this:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axel Reichert <mail@axel-reichert.de> writes:

Julieta Shem <jshem@yaxenu.org> writes:

Axel Reichert <mail@axel-reichert.de> writes:

I somewhere read that Guile is the most Common-Lisp-like of the
Scheme implementations (if you ask for it, I will try to dig up the
link).

Dig it up! Let's read it and discuss it. You're invited. :-)

https://ane.iki.fi/2020/10/05/between-two-lisps.html

Fun to read. There isn't much I'd like to add or comment. I agreed
with everything I read.

Somewhat more biased, and, strictly speaking, off-topic here:

https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations

Less fun to read.

Question. ``Use an existing implementation rather than writing your
own. Get good at using your REPL (or the IDE, in the case of Racket).''

I use ``IDE'' very loosely and it seems the author has a more precise definition. It seems s/he says Racket has an IDE. I suppose DrRacket.
And somehow that means Racket doesn't have a REPL?

I think you would like to speak C.

Sure. Not only because there is an awful lot of open source software
written in it, but also due its enormous historical importance.

Yes. It feels good to be close to the operating system so that you know exactly how things work.

https://www.buildyourownlisp.com/

(Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...

You'll enjoy it! This book is great fun. Each picture is a joke. I
offered the author one of my jokes. First picture in chapter 9 at

https://www.buildyourownlisp.com/chapter9_s_expressions

The idea is: ``OLD LISP: YOU HAD TO YELL AT IT TO GET THINGS DONE''.

What's the SD in Guix SD? Software distribution?

Ah, sorry, using the old name, nowadays it is just Guix System (the OS) versus Guix, the package manager.

And what did it mean?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julieta Shem <jshem@yaxenu.org> writes:

Axel Reichert <mail@axel-reichert.de> writes:

https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations

Less fun to read.

Why so? Too much "advocacy"?

Get good at using your REPL (or the IDE, in the case of Racket).''

I use ``IDE'' very loosely

Same here. Is Emacs' lisp-interaction-mode an IDE? If not, is Emacs plus
Geiser a Scheme/Guile IDE? If not, is Emacs plus SLIME an IDE? I think
the amount of "support" a tool offers for programming is more a
continuum than either a REPL or an IDE.

It seems s/he says Racket has an IDE. I suppose DrRacket.

Yes, that is probably meant.

And somehow that means Racket doesn't have a REPL?

No. I suppose the author sees IDEs as supersets of REPLs, so if you have
access to the former, it is to be preferred.

https://www.buildyourownlisp.com/

(Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...

You'll enjoy it! This book is great fun. Each picture is a joke.

Sounds good, thanks for your encouragement.

Ah, sorry, using the old name, nowadays it is just Guix System (the OS)
versus Guix, the package manager.

And what did it mean?

"System Distribution", see

https://en.wikipedia.org/wiki/GNU_Guix_System

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:

( SETQ DIFF
( LAMBDA( X )
...
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

That looks like some Lisp-1 (Scheme-type) dialect.

Also, we don’t like doing all uppercase code these days.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:

( SETQ DIFF
( LAMBDA( X )
...
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

That looks like some Lisp-1 (Scheme-type) dialect.

For now, I'm using, IIRC, "NewLisp" and

( setq SETQ setq )
( SETQ NULL null? )
( SETQ ATOMP atom? )
( SETQ T true )
( SETQ CAR first )
( SETQ CDR rest )
( SETQ PROGN begin )
( SETQ LENGTH length )
( SETQ COND cond )
( SETQ APPEND append )
( SETQ CADR( lambda( X )( CAR ( CDR X ))))
( SETQ CADDR( lambda( X )( CAR ( CDR ( CDR X )))))

. I was not able to convert "lambda" to uppercase, though.
So, I have to write:

( SETQ DIFF
( lambda( X )
( COND
...

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:

( SETQ DIFF
( LAMBDA( X )
...
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

That looks like some Lisp-1 (Scheme-type) dialect.

For now, I'm using, IIRC, "NewLisp" and

( setq SETQ setq )
( SETQ NULL null? )
( SETQ ATOMP atom? )
( SETQ T true )
( SETQ CAR first )
( SETQ CDR rest )
( SETQ PROGN begin )
( SETQ LENGTH length )
( SETQ COND cond )
( SETQ APPEND append )
( SETQ CADR( lambda( X )( CAR ( CDR X ))))
( SETQ CADDR( lambda( X )( CAR ( CDR ( CDR X )))))

. I was not able to convert "lambda" to uppercase, though.
So, I have to write:

( SETQ DIFF
( lambda( X )
( COND
...

.

Likely because lambda is syntax, not a symbol.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julieta Shem <jshem@yaxenu.org> writes:

Likely because lambda is syntax, not a symbol.

The Hyper Spec (indirect quotation) does call "lambda" a "symbol":

|lambda expression n. a list which can be used in place of a
|function name in certain contexts to denote a function by
|directly describing its behavior rather than indirectly by
|referring to the name of an established function; its name
|derives from the fact that its first element is the symbol
|lambda.

. Since I use "NewLisp", what should be relevant in my case should
actually be NewLisp! The NewLisp manual says indeed:

|Note that the lambda keyword is not a symbol in a list,
|but a designator of a special type of list: the lambda list.

. Insofar, you are right when you say it's not a symbol!
It's a keyword (in NewLisp).

I'd hesitate to call lambda "syntax", but I thing you might meant
to say it's /part of/ the syntax, which is what a keyword is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Julieta Shem <jshem@yaxenu.org> writes:

Likely because lambda is syntax, not a symbol.

The Hyper Spec (indirect quotation) does call "lambda" a "symbol":

|lambda expression n. a list which can be used in place of a
|function name in certain contexts to denote a function by
|directly describing its behavior rather than indirectly by
|referring to the name of an established function; its name
|derives from the fact that its first element is the symbol
|lambda.

. Since I use "NewLisp", what should be relevant in my case should
actually be NewLisp! The NewLisp manual says indeed:

|Note that the lambda keyword is not a symbol in a list,
|but a designator of a special type of list: the lambda list.

. Insofar, you are right when you say it's not a symbol!
It's a keyword (in NewLisp).

I'd hesitate to call lambda "syntax", but I thing you might meant
to say it's /part of/ the syntax, which is what a keyword is.

We'll never go wrong if we say it's just energy. :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
for Racket. Maybe I'm too stupid for Racket.

The full #racket language is very powerful and it can be difficult to
learn. However, there are a number of dedicated "learning" languages
which limit what the programmer can do, and have better error messages
to help newbies.

It also accepts standard R5RS and R6RS Scheme.

You can change the language the compiler accepts by putting #<lang> at
the top of the file, where <lang> is the language you want to use.

See the section on Teaching at https://docs.racket-lang.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

George Neuner <gneuner2@comcast.net> writes:

On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

It's hard to pinpoint what it is with Racket. Maybe I'm not good enough >>for Racket. Maybe I'm too stupid for Racket.

The full #racket language is very powerful and it can be difficult to
learn. However, there are a number of dedicated "learning" languages
which limit what the programmer can do, and have better error messages
to help newbies.

--8<---------------cut here---------------start------------->8---
Everything I say below is about me. I'm not at all evaluating anyone's
work from a non-particular and non-personal perspective.
--8<---------------cut here---------------end--------------->8---

Their error messages are very clear in these teaching languages. I'm
very grateful for having read HtDP. I consider it very highly --- I
feel there is no other publication that matches it on the objective it
set for itself. It's a unique book in the whole world to the best of my knowledge.

I think there might be a non-small gap between HtDP and the Racket
language. I think the authors might recognize this because some of them
also wrote other books on the Racket language. I would believe that
their advice for someone like me would be to, having read HtDP, follow
up with the ``Realm of Racket'', say, which I have /tried/ and confess
the gaming context was an obstacle --- it's not like I can't abstract
all that away and focus on the language only. (I despise computer
games.)

Let's take a look at Beautiful Racket, which I've also read. Marvelous
work in the sense of showing what Racket can do, but I think it fails in teaching because when I read a programming language book I'm putting an engineer hat and looking for intuition on how things work on the inside
so that I can manipulate those primitives and build something I can
dream up. Beautiful Racket gives you tools that hide how the language
works (in the spirit of easeing the burden on the beginner's shoulders),
so after finishing the book, you must still continue to dig to see the
deeper level. It's the opposite of a draft such as

https://felleisen.org/matthias/lp/

that I found by accident in the last days. It's been great reading for
me. Also in the last days I've been trying to read the Evaluation
Model, but it's a bit difficult for a beginner. The draft above is
helpful because it seems to show Racket works in a very simplified
manner from the ground up in a pedagogical context.

Another hypothesis I've been considering lately (to explain my failures)
is that Racket has been taking the language-orientation hard and that
doesn't help a beginner to climb up slowly (with my psychology and
background). Let me elaborate on this point. People here gave me the try-Common-Lisp insight in the last days. I ``invented'' some
program-project to write in it and I've been writing it (very slowly)
and having a lot of fun. But why? I think it's because of the
permissiveness of Common Lisp. Here's an example. I created a macro
that avoided some redundancies but it actually needed a variable capture
to even do what I wanted. I wanted the very wrong thing. I did it, saw
it working and then found a way of not committing such ``grave'' crime.
In Racket, I think I would not even manage to pull something like that
off because the language is designed to avoid such crimes. This implies
I need proper education before I can play with it and that seems to hurt
my solo pedagogical adventure.

I believe that the more I do Common Lisp, the more I understand Racket.
By seeing the crime I was committing, I thought of Racket --- ``oh,
maybe that's why Racket macros must received syntax objects with lexical
and scope information to go along with it''. ``The compiler won't let
me mix them up unless I learn how to hack these objects myself, which
being so clueless here I wouldn't even know how to do --- bummer. I
can't continue to do what I want, so I can't continue my Racket writing pratice. I need to continue my documentation harvesting and so on and
maybe some days later I can come back to the writing.'' Sure I can ask
for help and so on. I've been doing it. If a ladder is so steep that a
weak person can't go up, it seems to delay the moment where one finds
enough strength to go up.

I understand serious languages are designed to protect programmers from
making unwise things, but maybe that has an impact on education. Seeing
the lab explode is likely educational and things do not explode if
building the contraptions are sufficiently hard.

Keep in mind that I'm not asking the Racket language to be any easier on
me or somehow adapt to my psychology. I'm a USENET member, so I can
share my experience just for the fun of it. I should also say that
Common Lisp has allowed me in a few days to get an enthusiasm than I
haven't gotten with any Racket program I've written in the past --- I
wrote two small systems that worked in production for various years and
are now retired; both of them would periodically download information
from an API source, store it locally and serve it to other systems. I
totally consider that my Racket reading and (little) practice has surely prepared me for having all the fun I'm having with Common Lisp in the
last days.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Jan 2024 00:32:11 -0300
Julieta Shem <jshem@yaxenu.org> wrote:

example. I created a macro that avoided some redundancies but it
actually needed a variable capture to even do what I wanted. I
wanted the very wrong thing. I did it, saw it working and then found

Variable capture in macros isn't necessarily wrong. The book "Let Over Lambda"[1] by Doug Hoyte presents some interesting examples of
intentional variable capture in Common Lisp macros.


[1] https://letoverlambda.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Jan 2024 00:32:11 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

George Neuner <gneuner2@comcast.net> writes:

On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

It's hard to pinpoint what it is with Racket. Maybe I'm not good enough >>>for Racket. Maybe I'm too stupid for Racket.

The full #racket language is very powerful and it can be difficult to
learn. However, there are a number of dedicated "learning" languages
which limit what the programmer can do, and have better error messages
to help newbies.

--8<---------------cut here---------------start------------->8---
Everything I say below is about me. I'm not at all evaluating anyone's
work from a non-particular and non-personal perspective. >--8<---------------cut here---------------end--------------->8---

Their error messages are very clear in these teaching languages. I'm
very grateful for having read HtDP. I consider it very highly --- I
feel there is no other publication that matches it on the objective it
set for itself. It's a unique book in the whole world to the best of my >knowledge.

I think there might be a non-small gap between HtDP and the Racket
language. I think the authors might recognize this because some of them
also wrote other books on the Racket language. I would believe that
their advice for someone like me would be to, having read HtDP, follow
up with the ``Realm of Racket'', say, which I have /tried/ and confess
the gaming context was an obstacle --- it's not like I can't abstract
all that away and focus on the language only. (I despise computer
games.)

Let's take a look at Beautiful Racket, which I've also read. Marvelous
work in the sense of showing what Racket can do, but I think it fails in >teaching because when I read a programming language book I'm putting an >engineer hat and looking for intuition on how things work on the inside
so that I can manipulate those primitives and build something I can
dream up. Beautiful Racket gives you tools that hide how the language
works (in the spirit of easeing the burden on the beginner's shoulders),
so after finishing the book, you must still continue to dig to see the
deeper level. It's the opposite of a draft such as

https://felleisen.org/matthias/lp/

that I found by accident in the last days. It's been great reading for
me. Also in the last days I've been trying to read the Evaluation
Model, but it's a bit difficult for a beginner. The draft above is
helpful because it seems to show Racket works in a very simplified
manner from the ground up in a pedagogical context.

Another hypothesis I've been considering lately (to explain my failures)
is that Racket has been taking the language-orientation hard and that
doesn't help a beginner to climb up slowly (with my psychology and >background). Let me elaborate on this point. People here gave me the >try-Common-Lisp insight in the last days. I ``invented'' some >program-project to write in it and I've been writing it (very slowly)
and having a lot of fun. But why? I think it's because of the >permissiveness of Common Lisp. Here's an example. I created a macro
that avoided some redundancies but it actually needed a variable capture
to even do what I wanted. I wanted the very wrong thing. I did it, saw
it working and then found a way of not committing such ``grave'' crime.
In Racket, I think I would not even manage to pull something like that
off because the language is designed to avoid such crimes. This implies
I need proper education before I can play with it and that seems to hurt
my solo pedagogical adventure.

I believe that the more I do Common Lisp, the more I understand Racket.
By seeing the crime I was committing, I thought of Racket --- ``oh,
maybe that's why Racket macros must received syntax objects with lexical
and scope information to go along with it''. ``The compiler won't let
me mix them up unless I learn how to hack these objects myself, which
being so clueless here I wouldn't even know how to do --- bummer. I
can't continue to do what I want, so I can't continue my Racket writing >pratice. I need to continue my documentation harvesting and so on and
maybe some days later I can come back to the writing.'' Sure I can ask
for help and so on. I've been doing it. If a ladder is so steep that a
weak person can't go up, it seems to delay the moment where one finds
enough strength to go up.

I understand serious languages are designed to protect programmers from >making unwise things, but maybe that has an impact on education. Seeing
the lab explode is likely educational and things do not explode if
building the contraptions are sufficiently hard.

Keep in mind that I'm not asking the Racket language to be any easier on
me or somehow adapt to my psychology. I'm a USENET member, so I can
share my experience just for the fun of it. I should also say that
Common Lisp has allowed me in a few days to get an enthusiasm than I
haven't gotten with any Racket program I've written in the past --- I
wrote two small systems that worked in production for various years and
are now retired; both of them would periodically download information
from an API source, store it locally and serve it to other systems. I >totally consider that my Racket reading and (little) practice has surely >prepared me for having all the fun I'm having with Common Lisp in the
last days.

I never read any of those books 8-) I learned Scheme and dabbled with
Lisp long before Racket existed.


The thing to keep in mind is that Racket essentially is an enhanced
Scheme. *Most* of what you learn re: Scheme is transferable to
Racket. The major difference is that, by default, Racket has
immutable pairs (conses) and structs - so, e.g., simple demo programs
that use set-car! and set-cdr! just won't work.

Making your structs mutable is an option - the default idiom is RAII.

Also optional are immutable strings, vectors, hashtables, boxes, etc.
[some things can be done more efficiently when the compiler knows the
data won't change].

And if you really DO need mutable pairs in Racket, they do exist - but
as a separate type called 'mpair'. Or you can use #lang R5RS or R6RS
for code that needs mutable pairs. Any #lang module can export
functions to be used by any other #lang module.

[Honestly, except for a quick hack job, I have never had a use for
mutable pairs. Anything you can do with a pair is better done with a
struct or a box. That goes for Lisp as well.]


And for the rest: anything beyond what is in R_RS Scheme necessarily
is implementation specific. Racket has more to learn than some other implementations because, out-of-the-box, it addresses many programming
tasks ... but you learn things as you need them.

Typically it takes years to become really proficient with most
languages and/or their implementations: standard libraries, runtimes,
etc. Why should Racket be any different?


YMMV,
George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julieta Shem <jshem@yaxenu.org> writes:

having read HtDP. I consider it very highly

Yes, a nice and well-structured book.

Beautiful Racket gives you tools that hide how the language works (in
the spirit of easeing the burden on the beginner's shoulders), so
after finishing the book, you must still continue to dig to see the
deeper level.

Well, aren't Lisps supposed to be extremely high-level languages?

It's the opposite of a draft such as

https://felleisen.org/matthias/lp/

that I found by accident in the last days.

Thanks for the pointer, I did not know it.

I created a macro that avoided some redundancies but it actually
needed a variable capture to even do what I wanted.

Could it be that you re-invented anaphoric macros?

https://unintelligible.org/onlisp/onlisp.html#SEC99

"On Lisp" as a whole will probably suit you well.

I wanted the very wrong thing. I did it, saw it working and then
found a way of not committing such ``grave'' crime.

With your C background you should know that you can do many things as
long as you know what you are doing. (-:

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paolo Amoroso <info@paoloamoroso.com> writes:

On Mon, 15 Jan 2024 00:32:11 -0300
Julieta Shem <jshem@yaxenu.org> wrote:

example. I created a macro that avoided some redundancies but it
actually needed a variable capture to even do what I wanted. I
wanted the very wrong thing. I did it, saw it working and then found

Variable capture in macros isn't necessarily wrong. The book "Let Over Lambda"[1] by Doug Hoyte presents some interesting examples of
intentional variable capture in Common Lisp macros.

Thank you! I think that's chapter 6, anaphoric macros.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julieta Shem <jshem@yaxenu.org> writes:

Could it be that you re-invented anaphoric macros?

https://unintelligible.org/onlisp/onlisp.html#SEC99

Thank you for the name of it. Paolo Amoroso had already pointed out
Doug Hoyte's book. (Thanks, Paolo.)

"On Lisp" as a whole will probably suit you well.

Thank you!

... and will be far easier than "Let Over Lambda" (but still quite
advanced).

Best regards

Axel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axel Reichert <mail@axel-reichert.de> writes:

Julieta Shem <jshem@yaxenu.org> writes:

[...]

Beautiful Racket gives you tools that hide how the language works (in
the spirit of easeing the burden on the beginner's shoulders), so
after finishing the book, you must still continue to dig to see the
deeper level.

Well, aren't Lisps supposed to be extremely high-level languages?

The context here is Beautiful Racket. Instead of teaching you how to
use the Racket primitives, it teaches you how to use its own primitives.
So in practice you learn the Beautiful Racket language, not Racket. It
works like a tour to see what the Racket language can do if you master
it --- likely its very objective. But then when you're done, you still
need to study the Racket language. And with a POSIX background, you'll
wonder where things are in the Racket language as well.

It's the language barrier. You may know what you want to say, but if
you're in a new world you still need to learn all the new world's ways.

I created a macro that avoided some redundancies but it actually
needed a variable capture to even do what I wanted.

Could it be that you re-invented anaphoric macros?

https://unintelligible.org/onlisp/onlisp.html#SEC99

Thank you for the name of it. Paolo Amoroso had already pointed out
Doug Hoyte's book. (Thanks, Paolo.)

"On Lisp" as a whole will probably suit you well.

Thank you!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 20 Jan 2024 07:26:22 -0300
Julieta Shem <jshem@yaxenu.org> wrote:

Variable capture in macros isn't necessarily wrong. The book "Let
Over Lambda"[1] by Doug Hoyte presents some interesting examples of intentional variable capture in Common Lisp macros.

Thank you! I think that's chapter 6, anaphoric macros.

Yes, that's it. Paul Graham's classic "On Lisp" covers anaphoric macros
too.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paolo Amoroso <info@paoloamoroso.com> writes:

On Sat, 20 Jan 2024 07:26:22 -0300
Julieta Shem <jshem@yaxenu.org> wrote:

Variable capture in macros isn't necessarily wrong. The book "Let
Over Lambda"[1] by Doug Hoyte presents some interesting examples of
intentional variable capture in Common Lisp macros.

Thank you! I think that's chapter 6, anaphoric macros.

Yes, that's it. Paul Graham's classic "On Lisp" covers anaphoric macros
too.

Doug Hoyte mentions Paul Graham. He begins chapter 6 with

``Some of the most interesting macros from Paul Graham's On Lisp are
anaphoric macros.''

and promply discuss alambda:

--8<---------------cut here---------------start------------->8---
;; Graham's alambda
(defmacro alambda (parms &body body)
`(labels ((self ,parms ,@body))
#'self))
--8<---------------cut here---------------end--------------->8---

Paul Graham seems to credit Richard Draves for having ``rewrit[ten]''
alambda in 1985 (in ``Acknowledgements'').

--8<---------------cut here---------------start------------->8---
Several other people consented to read all or part of the manuscript,
including Tom Cheatham, Richard Draves (who also rewrote alambda and
propmacro back in 1985), John Foderaro, David Hendler, George Luger,
Robert Muller, Mark Nitzberg, and Guy Steele.
--8<---------------cut here---------------end--------------->8---

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-20, Julieta Shem <jshem@yaxenu.org> wrote:

Thank you! I think that's chapter 6, anaphoric macros.

Breaking news! Evidence of amphoric Lisp macros was found in an
acient Greek clay jar!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <433-929-6894@kylheku.com> writes:

On 2024-01-20, Julieta Shem <jshem@yaxenu.org> wrote:

Thank you! I think that's chapter 6, anaphoric macros.

Breaking news! Evidence of amphoric Lisp macros was found in an
acient Greek clay jar!

What's up? Are you saying the book is too old? Or I'm discovering a
very old thing? Beginners don't get the jokes. I also have no idea why
you misspelled ``anaphoric''---dictionary did not help.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)