Re: [Readable-discuss] using sweeten with newlisp

[David A. Wheeler]

>I suppose I could define a function that swaps the first 2 arguments
>then
>evaluates.  In newlisp, this won't cause any slowdown.

Curly-infix does a little more than that. Feel free to steal its code, it is 
under the MIT license.

If there are only three arguments, then it does indeed just swapped the first 
two arguments. However, if there are an odd number of arguments, where the 
number of arguments are three or more, and the even arguments are all 
identical, then the one even argument is the front and the rest are the final 
arguments. This lets you do things like this:

{a + b + c + {d * e }}



>ColorForth distinguishes between immediate and compiled words
> ... be
>nice to
>have that distinction in Lisp.

I've used several Forths and I own the book "Starting Forth".

Forth and Lisp are radically different.  That said, lisp does have ways to 
distinguish between actions taken while reading code, macros, and normal code.  
Scheme does not have a standard way to adjust the readtable (to control what 
happens while reading an expression) but common lisp does.  Common Lisp also 
has eval-when:
http://www.lispworks.com/documentation/lw50/CLHS/Body/s_eval_w.htm


I think that controlling infix is much better if handled by the reader in lisp.

--- David A.Wheeler

--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Re: [Readable-discuss] using sweeten with newlisp

[Alan Manuel Gloria]

On Thu, Sep 22, 2016 at 4:08 AM, David Walther <
da...@clearbrookdistillery.com> 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
> Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Re: [Readable-discuss] using sweeten with newlisp

[David Walther]

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.

For dictionaries, newLisp does it like this:

(define d:d) ; define d as a dictionary
(d a b)  ; assigns b to a in dictionary d
(d a); looks up a in d, returns the value

Dictionaries are first class objects in newlisp, but they don't nest.  They are
all defined and stored at the top level, called MAIN.  This is for garbage
collection reasons.

>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)

>> 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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Re: [Readable-discuss] using sweeten with newlisp

[David A. Wheeler]

On Tue, 20 Sep 2016 13:20:26 -0700, David Walther 
 wrote:
> Hi, nice work on sweet expressions.

Thanks!  And thanks for contributing to this mailing list.

> Could you add a newlisp mode for sweeten?

I'm fine with adding a new mode for sweeten... but I'm kind of hoping that *you*
would provide those improvements.  But I'd be happy to help you get there.
BTW, you probably want to improve "unsweeten", not "sweeten".

> The main issue is that the # character in newlisp is treated as "comment until
> end of line", and there are no #! (or #|?) style multiline comments.

Several things probably need parameters, e.g., the characters for
comments to the end of line, and multiline comments are supported.
Supporting Clojure has similar issues - there should be a few parameterizations.

There's already basic support for a Common Lisp mode.  In Common Lisp
it's probably better to use the implementation specifically for Common Lisp,
but for generic data processing modifying "unsweeten" might be easier.

> # has no other special meanings, it isn't a prefix for special data types.

Again, this sounds like something needing parameterization.

> ; means the same thing as it does in regular LISP.

So *both* # and ; begin comments? Interesting.
But that's not a big problem.

> Also there are a few things from bbcode, like [cmd][/cmd], and [text][/text]
> tag pairs.  [cmd][/cmd] is only used in interactive mode, but both tag pairs
> can be considered as literal multiline strings without escaping.

Another parameter, no big deal.

> Also, newLisp uses {} to delimit a literal string.  I am ok with {} literal
> strings being turned into quoted "" strings.  newlisp "" strings are escaped
> just like C and JavaScript.

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?

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/

> 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.

--- David A. Wheeler

--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

[Readable-discuss] using sweeten with newlisp

[David Walther]

Hi, nice work on sweet expressions.

Could you add a newlisp mode for sweeten?

The main issue is that the # character in newlisp is treated as "comment until
end of line", and there are no #! (or #|?) style multiline comments.

# has no other special meanings, it isn't a prefix for special data types.

; means the same thing as it does in regular LISP.

Also there are a few things from bbcode, like [cmd][/cmd], and [text][/text]
tag pairs.  [cmd][/cmd] is only used in interactive mode, but both tag pairs
can be considered as literal multiline strings without escaping.

Also, newLisp uses {} to delimit a literal string.  I am ok with {} literal
strings being turned into quoted "" strings.  newlisp "" strings are escaped
just like C and JavaScript.

Also, newlisp source code is in UTF-8.  Is sweeten UTF-8 compatible?

David


--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss