Re: [Readable-discuss] using sweeten with newlisp

[Alan M. G. <alm...@gm...>]

On Thu, Sep 22, 2016 at 4:08 AM, David Walther <
da...@cl...> wrote:

> On Wed, Sep 21, 2016 at 08:11:09AM -0400, David A. Wheeler wrote:
> >Okay.  Clojure uses {...} for hashes, so newLisp isn't the only Lisp
> where {}
> >has another meaning.  The question is, how should infix be handled?
> >It really needs some paired characters, and (...) are spoken for.
> >Does newLisp already assign [...] a meaning?
>
> newLisp uses [...] for the tag pairs previous mentioned [cmd] and [text],
> and
> the parser doesn't allow [ to be used as first character of a symbol.
>

Well, if currently the only place where [...] is allowed used are the tags
[cmd], [/cmd], [text], [/text], then I don't see a reason why we can't
automatically convert [a + [b * c]] to (+ a (* b c)) at the unsweeten level.

(but if you need readable lisp in your parser directly instead of via the
unsweeten converter, well, maybe it'll need to get overhauled...)



>If so, the best approach may be to use
> >«x + 1» : Left/right-pointing double-angle quotation mark, U+AB/U+BB.
> These are very well-supported (e.g., they are used for French quotations
> and are in Latin-1), and in many cases are the easiest to enter. There is a
> risk of them being too similar to the comparison operators < and >, but
> this doesn't seem too bad. Nested example: fact«n * «n - 1»»
> >
> >I discuss this here:
> >https://sourceforge.net/p/readable/wiki/Clojure/
>
> I suppose I could define a function that swaps the first 2 arguments then
> evaluates.  In newlisp, this won't cause any slowdown.  Then infix would
> look
> like this (similar to bourne shell [ function)
>
> > (define-macro (infix a b) (eval (extend (list b a) (args))))
> (lambda-macro (a b) (eval (extend (list b a) (args))))
> > (if (infix 1 = 2) 5 10)
> 10
> > (if (infix 1 = 1) 5 10)
> 5
>
> ColorForth distinguishes between immediate and compiled words... be nice to
> have that distinction in Lisp.  Then a symbol could behave like this at
> compile stage:
>
> (a = b) => (apply = (a b))
>
> (a = b or c > d) => (apply or (apply = (a b)) (apply > (c d)))
>
> Then we get into C style precedence rules.
>
> Since infix notation is really useful mostly for mathematical and logical
> comparisons, perhaps defining "m" for "math" would have to do the job for
> infix.  Where "m" is a full interpreter with precedence rules etc.
>
> (if (m a = b or c > d) e f)
>

I built an infix macro for Common Lisp before (it's what got me invited on
this list).  With precedence even.

Overall, we've found precedence to be less useful; see
https://sourceforge.net/p/readable/wiki/Precedence/

Also, depending on how newlisp handles macros, an infix macro might not be
as powerful as you think.  Classical motivating example for why we should
have infix handled at the reader rather than at the macro level:

{a + b} ; add the number a to the number b, yielding a number
(map . {a + b}) ; add the list of numbers a to the list of numbers b,
yielding a list of numbers.

The latter gets translated at the reader level to (map . (+ a b)),
equivalent to (map + a b), which fits how map is often used in Lisplikes.

If you use an infix macro, (map . (m a + b)), that probably will not work -
it's (map m a + b).  Even if you can run macros dynamically, consider that
typically + will be a function, not a list of functions.

SRFI-26 also provides a nice "cut" macro that also works well with
reader-level infix:

(cut - a <>) ; -> (lambda (<>) (- a <>)), a function that subtracts its
argument from a
(cut . {a - <>}) ; as above, a function that subtracts its argument from a


>
> >> Also, newlisp source code is in UTF-8.  Is sweeten UTF-8 compatible?
> >
> >It's *supposed* to be, as long as the underlying Scheme is.  It probably
> >hasn't been adequately tested that way, but if it's not, it's a bug and
> needs
> >to be fixed.
>
> I have some source code I can test it on.  UTF-8 lets me use mathematical
> symbols like "delta" and "differential" and theta, phi, and pi from high
> school
> trigonometry
>
> David
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Readable-discuss mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>