Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Friendly Introduction to Racket

geometridae.bearblog.dev

Post reply on HN
Print view View original

91–100 of 195 posts

Re: A Friendly Introduction to Racket

#91

Post by chowells »

so-cal-schemer wrote: post #70
chowells wrote: post #53

Earlier quoted context omitted.

That's not at all what local reasoning means. Local reasoning is the property that a piece of code contains (when including the call graph) everything that can affect what it does. All mutation of a value is kept within some scope of ownership of that value. If you want to understand a piece of code, you can do it by understanding that piece of code , not the program as a whole. Assembly makes non-local reasoning man…

Homoiconicity is orthogonal to local reasoning. It just means the syntax is represented by the native data format, nested lists. This does make code generation very straightforward with list processing primitives. Mutation in scheme is possible, via set! , and set-car! and set-cdr! , but it's not recommended. Functional program design side-steps the issue. see also: SICP: 3.1.3 The Costs of Introducing Assignment htt…

Yes, I know they're orthogonal. But every example of using macros I see in lisp is either some horrendous non-local logic, or something that can be done better using simpler tools. Where's the killer use case that clearly is good software engineering and not papering over the lack of another feature?

Re: A Friendly Introduction to Racket

#92

Post by so-cal-schemer »

ux266478 wrote: post #42

Nothing against Lisp, but to correct the record: > For decades, Lisp was the language of artificial intelligence. [...] Then came the "AI winter," funding dried up, and Lisp went from star to cult language. Lisp had fallen from relevance before then. Only the United States was still using it, and mostly out of technical debt and a stubborn refusal to move on. Prolog displaced it in the late 1970s, and even within the…

I've read a large factor was minicomputers and microcomputers running Unix in C became much more affordable, and when the Berlin Wall fell in 1989 DoD funding for powerful and expensive Lisp workstations quickly dried up. And the nascent free software Lisp offerings left a lot to be desired (to be developed).

This visualization of relative programming language popularity shows Lisp was the 3rd most popular general purpose language in Q1 of 1984 behind Pascal (a learning language?) and C.

(Prolog shows at 12th, then drops off the chart)

Most Popular Programming Languages: Data from 1958 to 2025

https://youtu.be/ZTPrbAKmcdo?t=116

Gabriel's perspective from 1990:

Lisp: Good News, Bad News, How to Win Big - Richard P. Gabriel - Lucid, Inc

https://dreamsongs.com/WIB.html

Re: A Friendly Introduction to Racket

#93

Post by shawn_w »

GregBuchholz wrote: post #88
soegaard wrote: post #85

Earlier quoted context omitted.

That has been in Racket for a long time.

I tried: #lang racket/base (let ((a '#0=(0 . #0#))) (display (car a))) ...over at https://onecompiler.com/racket ...and it didn't compile, complaining: read-syntax: `#...=` forms not enabled for `read-syntax` mode ...maybe there is a switch needed to enable it?

Yeah, there's a toggle for it in read-syntax mode.

https://docs.racket-lang.org/reference/Reading.html#%28def._...

Re: A Friendly Introduction to Racket

#94

Post by wild_egg »

> Emacs Lisp — millions of people run Lisp every day without knowing it, because their editor is a Lisp interpreter.

Are there seriously any emacs users who are completely unaware of elisp? Isn't elisp the entire point of picking emacs?

Re: A Friendly Introduction to Racket

#95

Post by GregBuchholz »

spdegabrielle wrote: post #77
gus_massa wrote: post #26

Earlier quoted context omitted.

Homoiconicity makes writing macros easy. If you don't like it, you can try https://rhombus-lang.org/ that is build on Racket and also has macros but uses a Python-like syntax.

Bicameral, Not Homoiconic https://parentheticallyspeaking.org/articles/bicameral-not-h...

Is Prolog bicameral? Because it has a `read` predicate? Is bicameral then just a matter of implementing a `read` function which returns a tree of tokens, which you could implement for C or Python? Which makes bicamerality a property of a library rather than a property of the language?

Re: A Friendly Introduction to Racket

#96

Post by GregBuchholz »

shawn_w wrote: post #93
GregBuchholz wrote: post #88

Earlier quoted context omitted.

I tried: #lang racket/base (let ((a '#0=(0 . #0#))) (display (car a))) ...over at https://onecompiler.com/racket ...and it didn't compile, complaining: read-syntax: `#...=` forms not enabled for `read-syntax` mode ...maybe there is a switch needed to enable it?

Yeah, there's a toggle for it in read-syntax mode. https://docs.racket-lang.org/reference/Reading.html#%28def._...

How do you get that to work?

  #lang racket
  (read-syntax-accept-graph #t)
  (let ((a '#0=(0 . #0#)))
    (display (car a)))
...which of course doesn't work, because `(read-syntax-accept-graph)` is a run-time thing, and the circular-list structure is a `read`-time thing.

I couldn't figure it out with this either:

https://stackoverflow.com/questions/51942188/read-syntax-for...

...just to make sure I wasn't going crazy, this:

  (let ((a '#0=(0 . #0#)))
    (display (car a)))
...does work as expected with this online scheme interpreter:

https://www.jdoodle.com/execute-scheme-online

Re: A Friendly Introduction to Racket

#97

Post by so-cal-schemer »

chowells wrote: post #91
so-cal-schemer wrote: post #70

Earlier quoted context omitted.

Homoiconicity is orthogonal to local reasoning. It just means the syntax is represented by the native data format, nested lists. This does make code generation very straightforward with list processing primitives. Mutation in scheme is possible, via set! , and set-car! and set-cdr! , but it's not recommended. Functional program design side-steps the issue. see also: SICP: 3.1.3 The Costs of Introducing Assignment htt…

Yes, I know they're orthogonal. But every example of using macros I see in lisp is either some horrendous non-local logic, or something that can be done better using simpler tools. Where's the killer use case that clearly is good software engineering and not papering over the lack of another feature?

I believe this was built with macros:

Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp by taking great ideas from Haskell, Scheme, and OCaml.

https://coalton-lang.github.io/

Not well known, but surely good software engineering adding features. Lisp* is called the Programmable Programming Language for a reason.

pg wrote a treatise on Lisp macros (free download):

https://www.paulgraham.com/onlisp.html

(add to that something about great power - great responsibility and not holding it wrong)

Re: A Friendly Introduction to Racket

#98

Post by eru »

layer8 wrote: post #45
eru wrote: post #39

Earlier quoted context omitted.

Seems like a non-sequitur.

How so? Homoiconicity means that everything uses the same form of representation, and I’m familiar with how these things look in Lisp.

Homoiconicity doesn't mean everything has to _look_ the same.

If the term has any meaning, it's about how program source code can be represented and manipulated easily by the user. (And I say 'can' deliberately, because even Lisps still allow you to treat source code as a big flat string, if you want to.)

I don't think homoiconicity is all that much of a useful concept. It's very hard to pin down. Eg C can represent its own source code, too, if a bit clunkily. And Lisps generally don't execute by walking over s-expressions: their internal representation of their own logic typically uses more sophisticated structures (and adding native code compilers to the mix complicates matters further).

Re: A Friendly Introduction to Racket

#99

Post by BeetleB »

wild_egg wrote: post #94

> Emacs Lisp — millions of people run Lisp every day without knowing it, because their editor is a Lisp interpreter. Are there seriously any emacs users who are completely unaware of elisp? Isn't elisp the entire point of picking emacs?

Most Emacs users I personally know simply treat it as an editor. They're not really aware how it works under the hood.

Re: A Friendly Introduction to Racket

#100

Post by eru »

jibal wrote: post #52
eru wrote: post #38

Earlier quoted context omitted.

C has homoiconicity: you can represent C source code as C strings.

You can't run that code within the language so no, obviously not. And even if you could, strings + eval alone is not homoiconicity--programs are not manipulated by the compiler as unstructured text strings.

> You can't run that code within the language so no, obviously not.

Of course, you can. C is perfectly capable of writing C interpreters and compilers.

> And even if you could, strings + eval alone is not homoiconicity--programs are not manipulated by the compiler as unstructured text strings.

Lisps (typically) don't execute by walking over s-expressions, either. Lisp interpreters and compilers use more sophisticated representations.

Post reply on HN