4 ms·

So it just desugars into Python? I see there is a section in the documentation for macros, but there's nothing there. Does it support AST macros right now? I th

by anaphor 13y ago

So it just desugars into Python? I see there is a section in the documentation for macros, but there's nothing there. Does it support AST macros right now? I thought of doing something similar to this except doing some kind of static or gradual typing (that would be a larger project though).

Foxboron 13y ago
It desugars into python's AST, not python.
haney 13y ago
I've had similar ideas. I really like the batteries that are included with python but I would like to be able to add type annotations that are enforced to my code base for type safety. I also really like the idea of being able to extend the language with macros. Hy certainly seems like a good start towards a language like this.
- anaphor 13y ago
  I think the problem with adding even gradual typing to Python is how to handle duck typing. A lot of existing Python code relies on implicit assumptions about the parameters of functions, e.g. "this is an iterable" or "this is a number or supports some numeric operations". I know there are some Python libraries that formalize interfaces like this, but I can't see a good way of doing it nicely in general and being able to calculate the types of everything (with or without explicit annotations). Someone can correct me if I'm wrong but I don't think Scala or Clojure code has this problem.
  - haney 13y ago
    I hadn't thought about the duck typing issue. What I have in my mind is more akin to contract programming. I'd love to take a look at a library that does this. I just hacked something together during my layover to give it a try.
  - toxik 13y ago
    There is something called "abstract base classes" which provide the sort of interface testing you're asking for. You can, in Python, see if a thing supports (or more precisely claims to support) item access, iteration, sequence behavior, etc.
paultag 13y ago
Original author of hylang here - because lisp is homoiconic, you have real macros, not AST macros; although the distinction isn't exactly clear, it's nice to have them as first-class members of the language, and allow them to avoid caring about stmt vs expr internally. Happy to answer questions.
- anaphor 13y ago
  I disagree that homoiconicity is required. Racket is not homoiconic and its macros are pretty powerful (Template Haskell is probably a clearer example but is arguably less powerful). What do you lose by not making the syntax homoiconic? Also what is your definition of homoiconicity?
  - derp_dogg 13y ago
    I thought Racket was homoiconic. You can turn executable code into a data structure by quoting it (e.g. (+ 1 2) is executable code, but '(+ 1 2) is a data structure.) Wikipedia thinks Racket is homoiconic FWIW [ http://en.wikipedia.org/wiki/Homoiconic http://en.wikipedia.org/wiki/Homoiconic ]
    - anaphor 13y ago
      Racket does not use S-Expressions internally, it uses syntax objects which are not really the same. Furthermore it makes no sense to even ascribe one surface syntax to Racket since it's more than one language really. Also if you ask the main developers of Racket if it's homoiconic they would probably tell you that it's irrelevant (and they would be right). In fact I have this in my IRC logs, "<samth> homoiconicity is a meaningless term that tells you nothing about macros"
      - paultag 13y ago
        It's not meaningless, a lot of people (myself included) use it to talk about programs that can alter their own program in the data structures that they're good at moving around. In Python, the AST approximates this. Perhaps I'm lax in usage, but I think there's a continuum of homoiconicity - some things (like C) have no language functionality to deal with their own source code. Other languages (like CL) are very good at this, since you write the language in it's own data structures. Other languages (like Python, or Racket) aren't homoiconic, but they approximate what makes homoiconicity special.

by anaphor 13y ago

Foxboron 13y ago

It desugars into python's AST, not python.

haney 13y ago

I've had similar ideas. I really like the batteries that are included with python but I would like to be able to add type annotations that are enforced to my code base for type safety. I also really like the idea of being able to extend the language with macros. Hy certainly seems like a good start towards a language like this.

anaphor 13y ago
I think the problem with adding even gradual typing to Python is how to handle duck typing. A lot of existing Python code relies on implicit assumptions about the parameters of functions, e.g. "this is an iterable" or "this is a number or supports some numeric operations". I know there are some Python libraries that formalize interfaces like this, but I can't see a good way of doing it nicely in general and being able to calculate the types of everything (with or without explicit annotations). Someone can correct me if I'm wrong but I don't think Scala or Clojure code has this problem.
- haney 13y ago
  I hadn't thought about the duck typing issue. What I have in my mind is more akin to contract programming. I'd love to take a look at a library that does this. I just hacked something together during my layover to give it a try.
- toxik 13y ago
  There is something called "abstract base classes" which provide the sort of interface testing you're asking for. You can, in Python, see if a thing supports (or more precisely claims to support) item access, iteration, sequence behavior, etc.

paultag 13y ago

Original author of hylang here - because lisp is homoiconic, you have real macros, not AST macros; although the distinction isn't exactly clear, it's nice to have them as first-class members of the language, and allow them to avoid caring about stmt vs expr internally. Happy to answer questions.

anaphor 13y ago
I disagree that homoiconicity is required. Racket is not homoiconic and its macros are pretty powerful (Template Haskell is probably a clearer example but is arguably less powerful). What do you lose by not making the syntax homoiconic? Also what is your definition of homoiconicity?
- derp_dogg 13y ago
  I thought Racket was homoiconic. You can turn executable code into a data structure by quoting it (e.g. (+ 1 2) is executable code, but '(+ 1 2) is a data structure.) Wikipedia thinks Racket is homoiconic FWIW [ http://en.wikipedia.org/wiki/Homoiconic http://en.wikipedia.org/wiki/Homoiconic ]
  - anaphor 13y ago
    Racket does not use S-Expressions internally, it uses syntax objects which are not really the same. Furthermore it makes no sense to even ascribe one surface syntax to Racket since it's more than one language really. Also if you ask the main developers of Racket if it's homoiconic they would probably tell you that it's irrelevant (and they would be right). In fact I have this in my IRC logs, "<samth> homoiconicity is a meaningless term that tells you nothing about macros"
    - paultag 13y ago
      It's not meaningless, a lot of people (myself included) use it to talk about programs that can alter their own program in the data structures that they're good at moving around. In Python, the AST approximates this. Perhaps I'm lax in usage, but I think there's a continuum of homoiconicity - some things (like C) have no language functionality to deal with their own source code. Other languages (like CL) are very good at this, since you write the language in it's own data structures. Other languages (like Python, or Racket) aren't homoiconic, but they approximate what makes homoiconicity special.