Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 16 10:29
    Cloud11665 starred gilch/hissp
  • Jun 15 12:17
    kvnsmth starred gilch/hissp
  • Jun 11 21:59
    SolaWing starred gilch/hissp
  • Jun 10 16:32
    flashcactus starred gilch/hissp
  • May 19 14:28
    jedhsu starred gilch/hissp
  • May 17 19:50
    ben-denham starred gilch/hissp
  • May 16 03:30
    tkukushkin starred gilch/hissp
  • May 15 18:16
    codecov-commenter commented #98
  • May 15 18:16
    gilch synchronize #98
  • May 15 18:16

    gilch on typos

    Add trailing comma in readerles… (compare)

  • May 15 17:55
    codecov-commenter commented #98
  • May 15 17:54
    gilch synchronize #98
  • May 15 17:54

    gilch on typos

    Update README.md fix parenthes… (compare)

  • May 14 03:55
    gilch opened #99
  • May 10 06:12
    codecov-commenter commented #98
  • May 10 06:12
    gilch opened #98
  • May 10 06:11

    gilch on typos

    fix or or (compare)

  • May 09 16:51
    gilch closed #75
  • May 09 16:50
    gilch labeled #37
  • May 09 16:50
    gilch closed #37
Mike Pelletier
@salixbipedis:matrix.org
[m]
Hmm, I guess I see this behaviour in lissp_quickstart.rst so I suppose it's intentional. I think I'm meant to use the [] reader macro or (enlist ...)
gilch
@gilch
Other objects evaluate to themselves, but strings and tuples have special evaluation rules in Hissp. Tuples represent Hissp code and strings represent Python code (plus module literals).
You might have been trying to do this:
#> (list '(.#"a string" .#"another string"))
>>> list(
...   ('a string', 'another string'))
['a string', 'another string']
Mike Pelletier
@salixbipedis:matrix.org
[m]
Thanks. That is what I need to understand.
I'll look into why I need to use code injection there
gilch
@gilch
In Lissp, the "..." read syntax creates the Python code for a string.
So at the Hissp level, it becomes "('...')".
If you want to inject a string directly to the Hissp level, you use .#.
Mike Pelletier
@salixbipedis:matrix.org
[m]
Whereas .#"..." does not become a bare ellipsis, nor a string?
I get the voodoo now I just don't get how it works, but I can figure that out
gilch
@gilch
It might help to play around with readerless mode in Python.
salixbipedis
@salixbipedis:matrix.org
[m]
lissp renders to a tree of tuples containing tuples and strings so it does make sense that it chokes on the thing I made, I'm having trouble figuring out exactly how .# fixes it. I'll go play with readerless.
gilch
@gilch
#> ...
>>> ...
Ellipsis
#> .#"..."
>>> ...
Ellipsis
#> '.#"..."
>>> '...'
'...'
Mike Pelletier
@salixbipedis:matrix.org
[m]
aaahhh okay
so from another perspective I'm basically removing one level of quoting which is exactly what I want
----------------------------------------------------------------------
Ran 1 test in 0.002s

OK
Thanks! :-D
gilch
@gilch
#> '(list '("a string" "another string"))
>>> ('list', ('quote', ("('a string')", "('another string')")))
('list', ('quote', ("('a string')", "('another string')")))
#> '(list '(.#"a string" .#"another string"))
>>> ('list', ('quote', ('a string', 'another string')))
('list', ('quote', ('a string', 'another string')))
#> '"..."
>>> "('...')"
"('...')"
#> '.#"..."
>>> '...'
'...'
#> ''.#"..."
>>> ('quote', '...')
('quote', '...')
salt rock lamp
@elementio:salt-rock-lamp.ems.host
[m]
why is it represented as "('a string')" in python and not e.g. '"a string"'?
gilch
@gilch
The compiler does do a little bit of preprocessing when it evaluates strings, to make the module literals work, but it skips that step if it detects parentheses.
#> .#"'math..tau'"
>>> __import__("'math").tau'
  File "<console>", line 1
    __import__("'math").tau'
                            ^
SyntaxError: EOL while scanning string literal
#> .#"('math..tau')"
>>> ('math..tau')
'math..tau'
gilch
@gilch
I originally had the "..." Lissp read syntax evaluate to ('quote','...'), which still works in readerless mode, but realized I could simplify it after implementing strings in Hebigo. I wanted Lissp and Hebigo to work the same way for better compatibility, and it was easier to make them both work Hebigo's way, so here we are.
A space also works:
#> .#"'math..tau' "
>>> 'math..tau'
'math..tau'
Mike Pelletier
@salixbipedis:matrix.org
[m]
I haven't looked at Hebigo because s-expressions are important to the pleasant feelings lisp gives me. Should I?
Mike Pelletier
@salixbipedis:matrix.org
[m]
Might as well implement my program a third time and find out
Mike Pelletier
@salixbipedis:matrix.org
[m]
(.bar foo baz) and (foo.bar baz) compile to the same thing. Is one to be preferred in any context?
Mike Pelletier
@salixbipedis:matrix.org
[m]
Feels like a style issue but the guide doesn't mention it
gilch
@gilch
(foo.bar ...) can only work if both foo and bar are symbols. (.bar foo ...) works even if you replace foo with a non-symbol expression.
E.g. (.upper "shout!") works, but ("shout".upper) is a syntax error.
The cascade macro works with the (.bar ...) form.
If bar isn't a symbol either, you can still use Python's getattr.
gilch
@gilch
You should check out Hebigo. Its syntax corresponds pretty directly to S-expressions, so it has the same pleasant feel for me, but it's pretty like Python. If you edit Lisp with Parinfer, I think it's kind of similar. If you're used to paredit though, you might want to stick to Lissp. Because of the direct correspondence to S-expressions, something similar to paredit could theoretically be made for Hebigo, but it doesn't exist yet.
But Hebigo is more than just a reader. It also has a collection of macros that are more powerful than what comes with Lissp.
Unlike the basic macros, Hebigo's do require Hebigo to be installed to work though.
Note that because both Hebigo and Lissp read to Hissp, their macros are compatible. You can use Hebigo's macros in Lissp and compiler macros written in Lissp in Hebigo.
gilch
@gilch
I had to bootstrap Python-like macros to make Hebigo usable, and I wanted them to be powerful and Python-like instead of minimal, so I wrote them in readerless mode.
Reading through them will probably help you to understand how macros work in Lissp as well. Check it out: https://github.com/gilch/hebigo/blob/prototype/src/hebi/bootstrap.py
gilch
@gilch
I think sometimes internal method calls like (self.assertEqual foo bar) read better than (.assertEqual self foo bar).
Maybe because self feels less like an argument and more like a namespace in that case.
Classes kind of conflate ideas that are probably better kept separate.
Mike Pelletier
@salixbipedis:matrix.org
[m]
Thank you very much for your insights.
gilch
@gilch
@daehwannam defmacro can be used in a progn, it just doesn't take effect until the next form (because the current form has already been compiled by the time the macro is defined).
However, a macro defined at read time would be available at compile time in the same form:
#> (progn
#.. .#(defmacro x () (print 'hi) 42)
#.. (x))
hi
>>> # progn
... (lambda :(
...   None,
...   # x
...   (42))[-1])()
42
#> (progn
#.. .#(alias op/ operator..)
#.. (op/#add 1 1))
>>> # progn
... (lambda :(
...   None,
...   __import__('operator').add(
...     (1),
...     (1)))[-1])()
2
gilch
@gilch
It's even available at read time, as long as the reader has processed the definition first, like in a separate or nested inject.
Daehwan Nam
@daehwannam
@gilch Thank you for looking over my example code and pointing out my misunderstanding of macros. The injection macro .# somewhat similar to Hy's eval-and-compile. I need to take a closer look at Hissp's document later :)
gilch
@gilch
I based it on Common Lisp's "Sharpsign Dot" reader macro: http://www.lispworks.com/documentation/HyperSpec/Body/02_dhf.htm
Daehwan Nam
@daehwannam
Thanks for the information!
rajeevn1 @rajeevn1