Hacker News Reader

Comment by yters | Hacker News Reader

I'm trying to think of an easy way this idea can be hacked together with existing tools, instead of writing a bunch of new stuff.

Could this be handled by macro programming on a lisp machine? Lisp is essentially the parse tree, which all languages have, so it provides the syntax agnostic representation. Macros allow you to easily specify DSLs, plus the macros themselves are lists and thus manipulable by macros. The lisp machine is essentially emacs that really is an OS, so the entire programming environment is programmable. But, emacs on top of some shell isn't so bad either.

The only thing missing is the syntax layer. Maybe regexps could suffice? Also something like LaTeX can provide a rich variety of symbols and symbolic structures for syntax.

View on HN

Regexps alone are a really poor fit for dealing with recursive structures, such as finding matching pairs of braces. You can use them for a lexing step, but you're probably better off using something like yacc or LPEG for the parsing.

Forth, Factor, and other stack-based languages also have this same property of "syntax agnostic representation". While on the surface they're kind of a backwards Lisp (due to postfix notation, with intermediate results pushed on a stack), both are dealing with nested lists of symbols, and very adept at dealing with things expressed the same way.

That's true about the nested structures. I was wondering if it is worthwhile to make lexing and parsing first class and changeable at runtime, and whether regexps would be a good way of doing this. The problem with relying on an external program is that making syntax conversion first class gets much more convoluted.

But, it isn't clear to me whether it is a good idea to make everything about LOP first class. I do like that feature of Lisp though.

Or, possibly, perl6 rules. One of the things I keep meaning to have a go at is taking Larry's gimme5 stuff (a slow but working implementation of much of the rules system in perl5 he's using to bootstrap the grammar) and bolting it back into perl5 so we can experiment with it more easily.

Forth is not adept at dealing with nested lists of anything. It doesn't have linked lists, garbage collection, or traditionally even heap allocation. It does have recursion, but it doesn't traditionally have local variables, and mutual recursion (really handy when you're doing anything related to ASTs) requires using DEFER or something. Do you have a lot of experience writing Forth?

Forth words are nested lists of other words (before compilation). It's not as good at dealing with nested data structures as Lisps, agreed, but the poster above is asking about syntax and DSLs.

As you pointed out, though, programs tend to have nested structures.

Before compilation, Forth words don't exist. During compilation, they are flat lists of other words, not nested lists of other words. After compilation, they can be just about anything. Forth is great for embedded DSLs but it's not because of its great ability to deal with nested lists of words.

I'm pretty knowledgeable about Lisp so if these ideas could be implemented just by using some existing tools together I'd probably know. This article goes much further than that.

As high-level as Lisp is, it's still a general-purpose, turing-complete language and as such there's always going to be a DSL that's better suited than it to solve a particular domain-specific problem.

While it's true that you can embed DSL's in Lisp easily with macros, that doesn't address the editing issue at all. Current IDE's are not so easily extensible to support the high-level semantics of new DSL's, so even if your DSL is 20x more expressive than vanilla Lisp in your domain, you lose a lot of that productivity to the lack of tool support for it which we've grown accustomed to having with general-purpose languages (syntax highlighting, dependencies, reverse-dependencies, parameter hinting, refactoring, etc).

Do you know if anyone has tried abstracting out the elements of a good IDE? Your list looks like it could be implemented with a table structure. All languages have similar dependency structures (as far as I know), so the IDE would just need to know the right syntax elements. I'm probably way over simplifying though. I'm not broadly experienced in many languages.

> Could this be handled by macro programming on a lisp machine?

Sure!

Now all we need is a lisp machine that anyone can run on modern hardware. Any ideas?

I'm not sure if you're joking. It has always been the case that you could run Lisp on stock hardware. Lisp machines were just an optimization for back in the day when hardware was slow and Lisp compilation techniques weren't well-known.

I didn't bring up Lisp machines. I'd like to see a Lisp OS of some kind, though.

This guy's trying to write one in Movitz:

http://www.emmett.ca/~sabetts/

Reply on news.ycombinator.com