5 ms·

Elixir has similar mechanisms. It's great to see language designers explore new ways of making a language homoiconic without pure s-expressions.

draegtun 13y ago
Rebol, Io, Smalltalk & Perl6 are also examples of non s-expression homoiconic languages.
- joe_the_user 13y ago
  c++ too ... just kidding But more seriously, it seems like once one starts expanding the definition, homoiconicity gets to be in the eye of the beholder. "In a homoiconic language the primary representation of programs is also a data structure in a primitive type of the language itself." So you can take a monster language (at least any one with an eval command - Perl5 say), expand it's syntactical definition and get a "homoiconic language". http://en.wikipedia.org/wiki/Homoiconicity http://en.wikipedia.org/wiki/Homoiconicity
  - StefanKarpinski 13y ago
    Fully agree – homoiconicity ends up being almost more of a standard library feature rather than an essential part of the core language. For example, how does the existence of Python's ast module [1] not make Python homoiconic? The main difference, it seems, is how much the language lets you leverage having a representation of code as data to generate code, e.g. with macros. There are projects like macropy [2], but the core Python language doesn't provide macros – although I can't really fathom why at this point since most of the features are there. [1] http://docs.python.org/3/library/ast.html http://docs.python.org/3/library/ast.html [2] https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
  - draegtun 13y ago
    I know what you mean. In my examples I think only Perl6 is stretching the definition of homoiconicity, NB. are Perl6 Grammars == data structure/primitive ?? However Rebol (blocks & words) & Io/Smalltalk (objects and messages) do fully meet the definition you give above for being an homoiconic language.
joe_the_user 13y ago
The serious question I would have about non-s-expressions language is - while they might be homoiconic by whatever definition, what makes them easy to parse? The thing that's appealing about s-expression languages is that code-as-data is easy to do because parse, creating and modifying code is dead-easy. Is there some still-very-easy algorithm for parsing things like infix operators or does code-as-data depend on using the facilities of the language. Edit: I can see Julia does this by reflection and macros. But I'm still curious about the general issues and algorithms involved here.
- krichman 13y ago
  > still-very-easy algorithm for parsing things like infix operators You would be interested in the shunting-yard algorithm[1], to start with. [1] https://en.wikipedia.org/wiki/Shunting_yard_algorithm https://en.wikipedia.org/wiki/Shunting_yard_algorithm
- draegtun 13y ago
  >The serious question I would have about non-s-expressions language is - while they might be homoiconic by whatever definition, what makes them easy to parse? Rebol is very easy to parse. Here is a Rebol parser in 10 lines of Rebol: parse text blk-rule: [ some [ str: newline | #";" [thru newline | to end] new: (probe copy/part str new) | [#"[" | #"("] blk-rule | [#"]" | #")"] break | skip (set [value new] load/next str probe :value) :new ] ] ref: http://www.rebol.net/cookbook/recipes/0042.html http://www.rebol.net/cookbook/recipes/0042.html
  - joe_the_user 13y ago
    That is interesting and I'm getting back late on this. But after mentally parsing that, it seems all this is doing separating blocks. What one would want to also do is to also scan operators, if one was evaluating code or transforming it into an abstract syntax tree.
    - draegtun 13y ago

draegtun 13y ago

Rebol, Io, Smalltalk & Perl6 are also examples of non s-expression homoiconic languages.

joe_the_user 13y ago
c++ too ... just kidding But more seriously, it seems like once one starts expanding the definition, homoiconicity gets to be in the eye of the beholder. "In a homoiconic language the primary representation of programs is also a data structure in a primitive type of the language itself." So you can take a monster language (at least any one with an eval command - Perl5 say), expand it's syntactical definition and get a "homoiconic language". http://en.wikipedia.org/wiki/Homoiconicity http://en.wikipedia.org/wiki/Homoiconicity
- StefanKarpinski 13y ago
  Fully agree – homoiconicity ends up being almost more of a standard library feature rather than an essential part of the core language. For example, how does the existence of Python's ast module [1] not make Python homoiconic? The main difference, it seems, is how much the language lets you leverage having a representation of code as data to generate code, e.g. with macros. There are projects like macropy [2], but the core Python language doesn't provide macros – although I can't really fathom why at this point since most of the features are there. [1] http://docs.python.org/3/library/ast.html http://docs.python.org/3/library/ast.html [2] https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
- draegtun 13y ago
  I know what you mean. In my examples I think only Perl6 is stretching the definition of homoiconicity, NB. are Perl6 Grammars == data structure/primitive ?? However Rebol (blocks & words) & Io/Smalltalk (objects and messages) do fully meet the definition you give above for being an homoiconic language.

joe_the_user 13y ago

The serious question I would have about non-s-expressions language is - while they might be homoiconic by whatever definition, what makes them easy to parse? The thing that's appealing about s-expression languages is that code-as-data is easy to do because parse, creating and modifying code is dead-easy. Is there some still-very-easy algorithm for parsing things like infix operators or does code-as-data depend on using the facilities of the language. Edit: I can see Julia does this by reflection and macros. But I'm still curious about the general issues and algorithms involved here.

krichman 13y ago
> still-very-easy algorithm for parsing things like infix operators You would be interested in the shunting-yard algorithm[1], to start with. [1] https://en.wikipedia.org/wiki/Shunting_yard_algorithm https://en.wikipedia.org/wiki/Shunting_yard_algorithm
draegtun 13y ago
>The serious question I would have about non-s-expressions language is - while they might be homoiconic by whatever definition, what makes them easy to parse? Rebol is very easy to parse. Here is a Rebol parser in 10 lines of Rebol: parse text blk-rule: [ some [ str: newline | #";" [thru newline | to end] new: (probe copy/part str new) | [#"[" | #"("] blk-rule | [#"]" | #")"] break | skip (set [value new] load/next str probe :value) :new ] ] ref: http://www.rebol.net/cookbook/recipes/0042.html http://www.rebol.net/cookbook/recipes/0042.html
- joe_the_user 13y ago
  That is interesting and I'm getting back late on this. But after mentally parsing that, it seems all this is doing separating blocks. What one would want to also do is to also scan operators, if one was evaluating code or transforming it into an abstract syntax tree.
  - draegtun 13y ago