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

Forth: The programming language that writes itself

ratfactor.com

Post reply on HN
Print view View original

151–160 of 174 posts

Re: Forth: The programming language that writes itself

#151

Post by lutusp »

DonHopkins wrote: post #144
lutusp wrote: post #32

Earlier quoted context omitted.

> As a child, I really was amused by the demo of GraFORTH on Apple ][, which included 3D wireframe animations, which at the time were magical. I originally wrote GraFORTH ( https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul ) to escape the slow world of integer BASIC on my first computer (an Apple II). Because it relied on large blocks of assembly code to produce nice graphics, it perhaps misled people about wha…

I used Graforth, that was so cool! I owe you a beer for pirating it. I also (like most Forth enthusiasts) developed my own Apple ][, based on FIG-FORTH, with its own graphics libraries and PRODOS integration, and used it to write terminal emulators. Then I discovered Mitch Bradley's Sun Forth (aka ForthMacs, Open Firmware, IEEE 1275-1994), which was originally based on Langton and Perry Forth 83, but has a metacompil…

My favorite John Draper story -- not sure if it's true, heard it from several sources.

One day IBM called me up and asked if I would write them something like Apple Writer, for their new PC. I instantly asked, "Under what terms?" I think that surprised them -- I was wrongly rumored to be all programmer and no business sense.

They replied, "We give you $100,000 in royalties, after which we own the program." I thought a bit and said, "Hmm ... $100,000 ... that's about 15 days of Apple Writer royalties." A long silence on the phone line.

So they realized I wasn't going to write anything for them. Then, according to rumor, they asked John Draper and he agreed -- he wrote them a word processor. A really terrible one.

After IBM voluntarily withdrew his program from the market, Draper is rumored to have said, "They asked for a $100,000 program and I gave them one."

Yep, we were pretty snotty in those days. But then, we didn't have to compete with AI.

Re: Forth: The programming language that writes itself

#152

Post by jedwards1211 »

procaryote wrote: post #39
behnamoh wrote: post #3

Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that ar…

Powerful languages invites people to do needlessly complex things. Needlessly complex things are harder to understand. Harder to understand is worse. Code that matters is usually read and extended many more times than it is written, over time by different people, so being straightforward beats most other things in practice

Stack-based programming may be simple but it doesn’t seem like it would be easy to read and understand for large-scale programs at all.

Re: Forth: The programming language that writes itself

#153

Post by kragen »

ErroneousBosh wrote: post #62
behnamoh wrote: post #3

Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that ar…

It's a different solution for a different time. Forth was an excellent way to write a powerful and expressive programming language that could self-host with a bare minimum of assembly language "bare metal" programming. The fridge-sized computer that Forth was originally developed on had double-digit kilobytes of memory (maybe 8192kwords, with 16-bit words) and clocked instructions through at a whopping 300kHz or so.…

What would your top two tips for beginning Forth programmers be? Other than "don't use Forth".

Re: Forth: The programming language that writes itself

#154

Post by ralphc »

lutusp wrote: post #32
nikolay wrote: post #5

Many people glorify the simplicity of Lisp as an interpreter, but Forth is similar and underappreciated. Sadly, the only code I've written in Forth is... PostScript. Yeah, PostScript is a dialect of Forth. As a child, I really was amused by the demo of GraFORTH on Apple ][, which included 3D wireframe animations, which at the time were magical.

> As a child, I really was amused by the demo of GraFORTH on Apple ][, which included 3D wireframe animations, which at the time were magical. I originally wrote GraFORTH ( https://archive.org/details/a2_GraFORTH_1981_Lutus_Paul ) to escape the slow world of integer BASIC on my first computer (an Apple II). Because it relied on large blocks of assembly code to produce nice graphics, it perhaps misled people about wha…

As a user, I'm just here to offer ::applause:: for GraFORTH.

Re: Forth: The programming language that writes itself

#155

Post by mikewarot »

behnamoh wrote: post #3

Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that ar…

>Why is it that languages like this don't scale?

I've concluded that Forth isn't as powerful as Lisp because it can't do lists or heaps. STOIC addresses these and other limitations. Unfortunately it's got the least search friendly language name ever.

Re: Forth: The programming language that writes itself

#156

Post by js8 »

actionfromafar wrote: post #83
js8 wrote: post #76

Earlier quoted context omitted.

That's a rather cheap retort. I am not saying everybody should use raw untyped lambda calculus for their programming, just that we would all benefit if we could translate languages we use to and from it, because then we could interoperate with any other code, refactor it, etc.

Isn’t structure lost in the compilation process? I mean, we already have bits and pieces of what you want, like an assembler to C decompiler, but the output isn’t very nice without the types. And how many languages can run on the CIL in dotnet. Say we create a CIL to lambda calculus compiler. Where do we go from there?

A CIL to LC compiler is effectively an emulator of CIL in LC. That is, every primitive of CIL has a corresponding LC term, which operates on the CIL execution state. So then you can express functions from .NET standard library as terms in LC.

Now let's say you do the same for JVM. Now you can start looking at all these lambda terms and search for some similarities. For example, you might notice that some list functions are equivalent if you transform the representation in a certain invertible way. This gives you a way to express functions from one standard library in the other.

In general, I think we should try to translate wide variety of human programs into lambda calculus and then try to refactor/transform the lambda terms to spot the common patterns.

Re: Forth: The programming language that writes itself

#157

Post by vacuity »

lproven wrote: post #74
CaptainOfCoit wrote: post #66

Earlier quoted context omitted.

> And we should aim for that, the babel tower of languages doesn't really help anyone. What exactly do you mean with this? That the amount of programming languages available isn't actually helpful, it's detrimental?

Certainly that is how I read it. It divides effort, spreads it too thinly among too many disparate projects with essentially the same goals, and as a result, they all advance much more slowly. Examples: how many successors to C are there now? Hare, Odin, Joy, Zig, Nim, Crystal, Jai, Rust, D... And probably as many again that are lower-profile or one-person efforts. For a parallel example, consider desktop environment…

The thing is, the most fundamental obstacle to unification, is that unification is a very hard feature to obtain. Even in an LC formalization, do you expect that two "text editor" programs would be interchangeable? Would only a canonical text editor be allowed? Does the LC facilitate arbitrary extensions, that perhaps follow some rules at the interface/boundary? While I also lament what is, on the whole, wasted work and interest, I think the alternative is not some much simpler solution, but rather to offer something that is better. https://xkcd.com/927 is a warning, as true as it is annoying. We gravitate towards variety because it is simpler and natural to how we act; how will your proposal fundamentally improve on this? You call out misguided "defenders", and again I note the same problem, but you seem to be calling for One True Way with no significant realizable improvement.

Re: Forth: The programming language that writes itself

#158

Post by eadmund »

kragen wrote: post #18
behnamoh wrote: post #3

Why is it that languages like this don't scale? It's not the first time I see a powerful language that got forgotten. Other examples include SmallTalk and Common Lisp (tiny community). It is because some languages are "too powerful"? What does that say about our industry? That we're still not that advanced of a specie to be able to handle the full power of such languages? I say that because it seems languages that ar…

I think those other languages have real advantages you aren't seeing. —·— The other day akkartik wrote an implementation of the program Knuth used to introduce literate programming to the CACM readers: https://basiclang.solarpunk.au/d/7-don-knuths-original-liter... It just tells you the top N words by frequency in its input (default N=100) with words of the same frequency ordered alphabetically and all words converte…

> splitting a line into words is a whole project on its own

Is it[1]? My version below accumulates alphabetical characters until it encounters a non-alphabetical one, then increments the count for the accumulated word and resets the accumulator.

    (let (c accumulator (counts (make-hash-table :test #'equal)))
      (handler-case
          (loop
            (setq c (read-char))
            (if (find c "ABCDEFGHIJKLMNOPQRSTUVWXYZ" :test #'char-equal)
                (push (char-downcase c) accumulator)
                (when accumulator
                  (incf (gethash (coerce (reverse accumulator) 'string) counts 0))
                  (setq accumulator nil))))
        (end-of-file ()
          (when accumulator
            (incf (gethash (coerce (reverse accumulator) 'string) counts 0))
            (setq accumulator nil))
          (maphash #'(lambda (word count)
                       (push (list count word) accumulator))
                   counts)
          (format t "~{~&~{~a ~a~}~%~}" (reverse (last (sort accumulator #'
It’s not exactly pretty or idiomatic, but its 19 lines appear to get the job done.

1: Well, technically it is, because there is SPLIT-SEQUENCE: https://github.com/sharplispers/split-sequence

Re: Forth: The programming language that writes itself

#159

Post by kragen »

eadmund wrote: post #158
kragen wrote: post #18

Earlier quoted context omitted.

I think those other languages have real advantages you aren't seeing. —·— The other day akkartik wrote an implementation of the program Knuth used to introduce literate programming to the CACM readers: https://basiclang.solarpunk.au/d/7-don-knuths-original-liter... It just tells you the top N words by frequency in its input (default N=100) with words of the same frequency ordered alphabetically and all words converte…

> splitting a line into words is a whole project on its own Is it[1]? My version below accumulates alphabetical characters until it encounters a non-alphabetical one, then increments the count for the accumulated word and resets the accumulator. (let (c accumulator (counts (make-hash-table :test #'equal))) (handler-case (loop (setq c (read-char)) (if (find c "ABCDEFGHIJKLMNOPQRSTUVWXYZ" :test #'char-equal) (push (cha…

Hey, this is great! Thanks!

It does look a lot like what I was thinking would be necessary. About 9 of the 19 lines are concerned with splitting the input into words. Also, I think you have omitted the secondary key sort (alphabetical ascending), although that's only about one more line of code, something like

  #'(lambda (a b)
       (or ( (cadr a) (cadr b)))))
Because the lines of code are longer, it's about 3× as much code as the verbose Perl version.

In SBCL on my phone it's consistently slower than Perl on my test file (the King James Bible), but only slightly: 2.11 seconds to Perl's 2.05–2.07. It's pretty surprising that they are so close.

Re: Forth: The programming language that writes itself

#160

Post by js8 »

tromp wrote: post #118
js8 wrote: post #41

Earlier quoted context omitted.

Because it is the simplest thing we have, and has a pretty straightforward self-interpreter. It feels like you need a lot more metamathematics to deal with typed lambda calculus than with untyped one, and types are something that comes without a justification. Anyway, the idea is, if you have a language, you can think of source code written in the language as a giant lambda term, where you have all lambdas upfront an…

> have all lambdas upfront and only composition in the body That is only possible for a very limited subset of lambda terms. For example, it's not possible for the one-point basis A = λx λy λz. x z (y (λw. z)) from which any closed lambda term can be constructed by composition.

Yes, that's deliberate though. (I will call these "concrete" terms, because they lack abstraction in the body, but I am looking for a good name. In fact, no universal one-point basis can be expressed as a single term like that, you need a composition of two; the concrete property is not preserved in composition, although it might be preserved in weaker bases than S,K, such as B,C,K - kind of affine logic.)

Anyway, the reason I am interested in concrete terms is I want to define typing judgements in ULC somehow. (In CoC, all mathematical questions can be rephrased as is there an object of given type T, and you need to be able to formalize questions somehow to formalize metamathematics.)

An obvious definition of typing judgement in ULC would be: term x is of type B in a typed language A (both A and B are given terms) iff there exists a term x that satisfies Ax = B (the equality is judgemental after beta-normalization).

However, this definition doesn't work, because a general term x can just disregard A and return B directly. But - I think if we restrict x to be a concrete term in the above definition (possibly with a given number of upfront lambdas - not sure if that is required), then I think we can make the definition to work.

I also suspect concrete terms can be sort of "deconstructed from the outside". In general, we cannot resolve equality of terms, but I suspect that concrete terms can be analyzed (and quoted) within ULC.

One thing I realized about your CoC implementation - I think you embed CoC into ULC in an indirect way, working with CoC terms in a quoted way. And that's fine, but what I want is to have CoC in ULC directly, i.e. have a base set of ULC terms for the primitives of CoC language. But that also can be thought of as the CoC interpreter being restricted to apply on concrete terms, giving them meaning by substituting the base inside.

In other words, concrete terms are kind of "inside view" of quoting. (Maybe we should call them "data terms", because they effectively carry only data and no executable payload.) Having the concept of concrete terms in the ULC metalanguage can also help to define interaction to the external world, that you only accept data not executables, something that you kinda do through the "monadic" interface. (You need to "remember" that a term only accepts quoted data, it cannot be made explicit in ULC language. The advantage of concrete terms is they are independent on your choice of quoting operator.)

Anyway, I am not sure if I am making sense, I am trying to grapple with this myself, so it's OK if you don't think concrete terms are a useful concept.

Post reply on HN