Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 28 17:24
    bskinn starred gilch/hissp
  • Jul 28 06:12
    gilch closed #101
  • Jul 28 06:12
    gilch locked #101
  • Jul 28 04:37

    gilch on more-macro-tutorial

    Add Decimal section to macro tu… (compare)

  • Jul 28 04:36
    mjreed-turner opened #101
  • Jul 28 01:55

    gilch on more-macro-tutorial

    Use difflib.context_diff for sy… (compare)

  • Jul 28 01:52

    gilch on more-macro-tutorial

    Add More Literals, Hexadecimal (compare)

  • Jul 27 20:06

    gilch on more-macro-tutorial

    Add More Literals, Hexadecimal (compare)

  • Jul 27 00:55
    codecov-commenter commented #100
  • Jul 27 00:54
    gilch synchronize #100
  • Jul 27 00:54

    gilch on doc-clarification

    Clarify paragraph about quoted … (compare)

  • Jul 25 02:54

    gilch on py3.8

    (compare)

  • Jul 25 02:45

    gilch on copy-edit

    (compare)

  • Jul 25 02:44

    gilch on deploy

    (compare)

  • Jul 25 02:43

    gilch on doc-fix

    (compare)

  • Jul 25 02:42

    gilch on doc-pass

    (compare)

  • Jul 25 02:42

    gilch on definite-defmacro

    (compare)

  • Jul 25 02:41
    codecov-commenter commented #100
  • Jul 25 02:40
    gilch opened #100
  • Jul 25 02:40

    gilch on doc-clarification

    add labels to letrec question (compare)

Mike Pelletier
@salixbipedis:matrix.org
[m]
I'll go read the quoting docs again
Mike Pelletier
@salixbipedis:matrix.org
[m]
Naively what I thought was happening was that "a string" was rendering to ('a string') which then got quoted a second time by the quote special form, transforming it into "('a string')" which doesn't seem intentional?
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