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 necessary when converting back
> to PicoLisp numbers.
>
> This should really be fixed ... I
On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote:
>: (pow 100.0 100.0) # This did not work
>->
> 1214215469580419574424931347467449492941767090953422917405833303694048810293471274498629572793183309320908289504788699434215946041483354800734678422429424402018
Awesome, thanks!
On Sun, Dec 12, 2021 at 9:25 AM Alexander Burger
wrote:
> On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote:
> >: (pow 100.0 100.0) # This did not work
> >->
> 1214215469580419574424931347467449492941767090953422917405833303694048810293471
Hi Alex,
I know I (ab)use 'fill' / 'macro' too much in my code, but I often want
to insert (not splice) the result of some calculation. Would you consider
a new '_' syntax within 'fill' forms?
: (fill (1 2 _ (+ 1 2))
-> (1 2 3)
This can currently be accomplished a few different ways
: (let X (+
Hi Erik,
> I know I (ab)use 'fill' / 'macro' too much in my code, but I often want
> to insert (not splice) the result of some calculation. Would you consider
> a new '_' syntax within 'fill' forms?
>
> : (fill (1 2 _ (+ 1 2))
> -> (1 2 3)
Hmm, I would not be very happy if we invent yet another
Hi Alex,
We stick with '^' only, but make it behave more intelligent:
>
>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.
>
> This would not break any existing programs, as atomic re
Hi list,
The rabbit hole went pretty deep. Here's my current viprc:
https://gist.github.com/erdg/ebf4556382bc1bbbaf534c4ebd927322
It now contains a substantial "command language" for lisp code based on
the keys '(', ')', '@' and '#'. There's also a bunch of utility functions
that
make writing th
