5 ms·
> ... this doesn't make sense. In order to have an ML, you take a subset of Common Lisp and specialize/extend it in a very specific direction. The part that ar
by junke 10y ago
> ... this doesn't make sense.
In order to have an ML, you take a subset of Common Lisp and specialize/extend it in a very specific direction. The part that are removed from Lisp are the one you don't care about. I care about being able to use different equivalence classes, including the ones the compiler is going to require, like identity equality, because this matters when I implement abstractions myself.
> However, there's no way to portably manipulate compiler internals in Haskell.
Yes, why not, that would be damn useful. The alternative is to hack each implementation in its own way.
> Heck, Haskell syntax, unlike Lisp syntax, can actually be represented in multiple ways: [...]
Do you get the difference between internal and external representations?
When you see (lambda (a) (+ a 1)), you don't know how the code is represented internally and how its value, when executed, is represented internally (when my compiler performs data-flow analysis, it uses a specific internal representation I don't need to know). Yet, you have access to a uniform API, defined at the language level, to manipulate data. That's why you can have the same source code working on the JVM, interpreted using a C/C++ runtime or directly expressed as assembly. In that sense, there is a separation between the language and its implementation. But part of the language specification is also there to guarantee a uniform way of building new extensions and integrate them with the compiler. That is a good thing. What is not enforced is how and when each feature is used. If that matters, dump a specialized Lisp image that you call the "compiler" and call it with Make on a file expressed in your custom DSL.
> There's no dichotomy between extensibility and abstraction enforcement, even if you try to set up one.
I am not trying to set up one. Just read more carefully.
- catnaroek 10y ago> Do you get the difference between internal and external representations? When you see (lambda (a) (+ a 1)), you don't know how the code is represented internally and how its value, when executed [emphasis mine], is represented internally I'm not talking about representations of semantic objects. I'm talking about representations of syntax. In Lisp's case, you don't get to choose - the macro system critically depends on a particular representation (named variables). Have fun writing macros that operate on HOAS.
- junke 10y ago> In Lisp's case, you don't get to choose - the macro system critically depends on a particular representation (named variables) Please tell me how Haskell represents HOAS and how this is not possible in Lisp. Also, read Barzilay's paper (http://scheme2006.cs.uchicago.edu/15-barzilay.pdf http://scheme2006.cs.uchicago.edu/15-barzilay.pdf), or about the Ergo Project (1988! http://repository.cmu.edu/cgi/viewcontent.cgi?article=2763&context=compsci http://repository.cmu.edu/cgi/viewcontent.cgi?article=2763&c...).
- catnaroek 10y ago> Please tell me how Haskell represents HOAS and how this is not possible in Lisp. I'm not talking about representing some object language's syntax in Haskell or Lisp. I'm talking about representing Haskell or Lisp's syntax in some other metalanguage (possibly Haskell or Lisp itself). How would you implement a macro expander that operates on HOAS? > Barzilay's paper (http://scheme2006.cs.uchicago.edu/15-barzilay.pdf http://scheme2006.cs.uchicago.edu/15-barzilay.pdf) The object language implemented in that paper isn't the whole of Scheme, and in particular, it doesn't have macros. > Ergo Project (1988! http://repository.cmu.edu/cgi/viewcontent.cgi?article=2763&context=compsci http://repository.cmu.edu/cgi/viewcontent.cgi?article=2763&c...) Sorry, I can't find an explicit description of any object language's syntax in this paper.
- kazinator 10y ago> How would you implement a macro expander that operates on HOAS? Hmm, you would expect that HOAS actually be helpful in this area in some ways. Since variables are no longer resolved by matching symbols to binding information in a scoped environment (all we have is direct names references to the binding inserted in the code, or something like that), we don't have hygiene issues when we move code around without having to do any alpha-renaming, or gensyms. It sounds rather convenient, unless we expressly want to do something non-hygienic. So how would we implement a macro expander? Like we implement anything else: in whatever way that implementation satisfies the specification of macros under HOAS. What is the specification: that is the question. What are HOAS macros, or macros under HOAS? Not having a formal specification, we might want at least some examples: OK, I have this HOAS artifact, and would like to be able to write it in a more condensed way using this other HOAS: now how to make one into the other? That gives us a function, where we can identify the inputs, which have to be arguments to the macro somehow and so it goes. Some kind of dual macro system could be useful: a raw source code macro system for doing un-hygienic things, and then a parallel one which kicks in when the code is converted to HOAS.