Re: Behavior of struct and single-precision floating-point

Fantastic. Thanks Alex! On Sun, Dec 12, 2021 at 4:33 AM Alexander Burger wrote: > Hi Kevin, hi all, > > On Thu, Dec 09, 2021 at 09:40:51PM +0100, Alexander Burger wrote: > > The conversion function can easily detect the type (short or big) when > > converting to float, and overflow to bignum if

Re: Feature request - 'fill'

Hi Erik, > >1. If the result of the evaluation is a list, we get the same result as > > now. > >2. But if the result is an atom, it is automatically 'cons'ed into a > > cell. > ... > Works for me! I also often want to use a returned list without splicing, > ... > : (macro (2 4 (^(mapcar '(

Re: Extending 'VIP' editor

Hi Erik, thats really cool! Thanks a lot for sharing! ☺/ A!ex On Sun, Dec 12, 2021 at 09:34:24PM -0600, Erik Gustafson wrote: > Hi list, > > The rabbit hole went pretty deep. Here's my current viprc: > > https://gist.github.com/erdg/ebf4556382bc1bbbaf534c4ebd927322 > > It now contains a subst

Re: Extending 'VIP' editor

Hi all. To Erik: Thank you for sharing, i am gradually starting to use parts of your viprc. I think it is very healthy to have viprc bigger than vip itself. To all: I think we should strive for small, clean and simple default version of Picolisp and Vip. Only put in ideas that are clean, powerful

Re: Feature request - 'fill'

Hi Alex, What should (fill (1 ^ 7 9)) return ? Regards, Andras Pahi > On 2021. Dec 13., at 18:21, Alexander Burger wrote: > > So I went ahead and implemented the extended 'fill' behavior. > > : (fill (1 ^(+ 1 1) 3)) > -> (1 2 3) > > To make it more consistent, I also changed the '~' read

Re: Feature request - 'fill'

Hi Andras, > What should (fill (1 ^ 7 9)) return ? -> (1 7 9) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Feature request - 'fill'

Hi Alex, Thank you for your answer. I’ve opted instead to return the usual (1 9) and only lists evaluating to atoms trigger the new behaviour in (fill). Regards, Andras Pahi > On 2021. Dec 13., at 21:01, Alexander Burger wrote: > > Hi Andras, > >> What should (fill (1 ^ 7 9)) return ? > >

Re: Feature request - 'fill'

Hi Andras, > I’ve opted instead to return the usual (1 9) and only lists evaluating to > atoms > trigger the new behaviour in (fill). Yes, a difficult decision. Still, I believe the new semantics are more useful. The expression following '^' can decide whether to return a list (possibly empty)

Re: Feature request - 'fill'

On Mon, Dec 13, 2021 at 09:28:07PM +0100, Alexander Burger wrote: > Yes, a difficult decision. And, as Razzy said, we should really, really be careful. To be not carried away by over-fantastic ideas. Recently, there were too many. Perhaps. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=

Re: Feature request - 'fill'

On Mon, Dec 13, 2021 at 6:27 PM Alexander Burger wrote: > > So I went ahead and implemented the extended 'fill' behavior. > >: (fill (1 ^(+ 1 1) 3)) >-> (1 2 3) > > To make it more consistent, I also changed the '~' read macro in the same > way. > Now this works: > >: (~(- 4 3) (2 ~(+

Re: Feature request - 'fill'

> And why not following lisp tradition and use comma character (,) rather > than caret > character (^) for evaluating expressions? > > In fact fill is more or less analogous to backquote (`) (also known as > quasiquote) in > several lisps : > > `(1 2 3) -> (1 2 3) > `(1 (+ 2 4) 3) -> (1 (+ 2 4)