Re: pgint.l

2019-01-17 Thread Michel Pelletier
Hi Abel,

Great work, I'll give it a shot on  pg 10 and 11 later today at work.  As
for the mailing lists, I'd start with pgsql-general mailing list before the
-hackers list, the same core devs watch both lists so you'll get the same
high grade advice.  They'll let you know if you should promote the issue to
-hackers.  The main advantage is, you'll get many more eyeballs on -general
and it's more appropriate given it's not a core dev issue.

-Michel

On Wed, Jan 16, 2019 at 11:05 PM Abel Normand 
wrote:

> Thanks all for your suggestions, I will open respective issues for minor
> improvements.
>
> Also mmamkin connected with me directly and also suggested to use prefix
> "pg-" for whole library not only for public functions. I think that I
> probably should to use namespaces to hide private functions. It would be
> nice if someone would share with me best practice for using them bcs I
> still do not have deep understanding in their usage.
>
> There is also a "postgresql-hackers" mailing list where devs discuss not
> only DBMS development but also clients and adapters implementation. So I
> think I should to share lib with them also, it probably will draw some
> attention to language itself and devs from pg community will advice
> something. What you think?
>
> Thanks.
> *From:* r...@tamos.net
> *Sent:* 16 January 2019 16:04
> *To:* picolisp@software-lab.de
> *Reply to:* picolisp@software-lab.de
> *Subject:* Re: pgint.l
>
> +1 for writing tests.
> +1 for using aw-‘s test harness.
> +1 for having a sane license.
>
> Huzzah! :)
>
>
>
>
> On Tue, 15 Jan 2019 21:11 +0300, Abel Normand wrote:
> > Hello everyone,
> >
> > I'm happy to announce that I released my small library to interfacing
> with
> > PostgreSQL -- https://gitlab.com/Abel-ze-Normand/pgint.l . I tried to
> keep
> > its implementation as simple as possible.
> >
> > I'm open to your suggestions for future improvements and your
> > contributions.
> > --
> > Best regards, Nail
>
>


Re: webassembly as a new lisp :) ?

2018-07-20 Thread Michel Pelletier
Interesting read thanks for pointing that out, a strange mashing of lisp
syntax with forth semantics, like

(func $add (param $lhs i32) (param $rhs i32) (result i32)
get_local $lhs
get_local $rhs
i32.add)

(get_local x) pushes one value onto the stack, and (i32.add) pops two and
pushes one.  In forth this would be something like:

: add ( x y -- z) i32.add ;

everything between the parens is a stack effect comment, there are no
explicit parameters (they get passed to add on the stack) or anything like
get_local, but the idea is the same, the work of the function pops two
stack items and pushes one.

-Michel

On Fri, Jul 20, 2018 at 9:42 AM, Jean-Christophe Helary <
brandel...@gmail.com> wrote:

> I was reading this article and found an eery similitude between
> WebAssembly text representation and Lisp. After looking a little further it
> appears that WebAssemble uses S-expressions.
>
> https://blog.scottlogic.com/2018/04/26/webassembly-by-hand.html
>
> https://developer.mozilla.org/en-US/docs/WebAssembly/
> Understanding_the_text_format
>
> Pretty cool :)
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>


Re: Wiki fonts etc.

2018-06-17 Thread Michel Pelletier
I am also slightly vision impaired and prefer higher contrast and/or larger
fonts.

Quite a few good tips here https://webaim.org/techniques/fonts/

On Sun, Jun 17, 2018 at 6:25 AM, Arie van Wingerden 
wrote:

> Hi all,
>
> being busy with the Wiki, I try to find some nice standards for fonts.
>
> On this page https://picolisp.com/wiki/?documentation all elements are
> used.
>
> I'd like to use:
>- main header:
> using current markup 4{ }
>- all sub headers:
> color: MidnightBlue;
> font-family: "Arial Black";
> font-size: 20px;
>- default Wiki font:
> font-family: "Verdana";
> font-size: 14px;
> font-weight: bold;
>  [Note: this font is shown in the top light blue paragraph]
>- special attention paragraphs:
> background-color: lightcyan;
> but using the default Wiki font.
>
> Personally I like blacker fonts, not the least because I myself have not
> all too good eyesight. So, I guess this would make it easier for a lot of
> folks.
>
> Furthermore the font is smaller than before, making it a bit more
> overseeable and compact (in the spirit of PicoLisp).
>
> If anybody has problems with those fonts, please let me know.
>
> If not, I'll ask Alex to update the default mark-up a bit.
>
> Best,
>Arie
>
>
>


Re: Ins and outs of the 'de' function

2018-05-24 Thread Michel Pelletier
Please do!  It's a small community and sometimes might feel like you're
talking to the walls, but we're paying attention.  I myself almost never
actually get to use picolisp, but I think it's an excellent example of
simplicity and minimalism language design, and it actually brought me to
become a lisp convert more than CL or scheme ever has.

A particular "aha" moment for me wrt picolisp was when I really understood
lambda expression:

https://software-lab.de/doc/ref.html#ev


On Thu, May 24, 2018 at 11:00 AM, Arie van Wingerden 
wrote:

> Hi,
>
> since first contact with PicoLisp I was convinced to it's possibilities,
> the small footprint and the extra's built-in, like GUI and DB.
>
> Since I've got some spare time, I am now trying to get a better grasp on
> things.
>
> Yesterday I already posted about some trial and error.
> Today, I tried to approach one function (de) in a structured manner and
> wrote it down.
>
> If and only if such things will be appreciated, I intend to continue bit by
> bit to create some useful docs with examples and a bit of extra explanation


Re: Mac OS

2018-04-09 Thread Michel Pelletier
I stand corrected, I was in the wrong terminal (on my mac) when I tried it.

But, you can still run picolisp in a docker container, which ends up being
similar to running it on a vm but a little easier to bootstrap.

-Michel

On Mon, Apr 9, 2018 at 5:32 PM, Amaury Hernández Águila <amhe...@gmail.com>
wrote:

> So you can compile the 64 bit version of PicoLisp on mac? I remember this
> wasn't possible.
>
> I have PicoLisp installed, but it's the 32 bit version.
>
> 2018-04-09 17:23 GMT-07:00 Michel Pelletier <pelletier.mic...@gmail.com>:
>
>> PicoLisp works fine on OS X (on x86-64), you just have to build it from
>> source using the instructions in the INSTALL file, I just verified it works
>> well.
>>
>>  Another option would be to use docker for mac and run the debian package
>> in a container, but that would be slower than a native install.
>>
>> -Michel
>>
>> On Mon, Apr 9, 2018 at 5:01 PM, Amaury Hernández Águila <
>> amhe...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> Is it going to be possible anytime soon to have 64-bit PicoLisp on Mac
>>> OS X? I'm deciding on what programming language to use for a project and I
>>> could consider PicoLisp.
>>>
>>
>>
>


Re: Mac OS

2018-04-09 Thread Michel Pelletier
PicoLisp works fine on OS X (on x86-64), you just have to build it from
source using the instructions in the INSTALL file, I just verified it works
well.

 Another option would be to use docker for mac and run the debian package
in a container, but that would be slower than a native install.

-Michel

On Mon, Apr 9, 2018 at 5:01 PM, Amaury Hernández Águila 
wrote:

> Hello!
>
> Is it going to be possible anytime soon to have 64-bit PicoLisp on Mac OS
> X? I'm deciding on what programming language to use for a project and I
> could consider PicoLisp.
>


Re: Chinese input causes mess in the REPL

2018-01-28 Thread Michel Pelletier
Ah yeah, thanks for clarifying that.  Does this "header only" C library
seem useful?  There's a lot of confusing stuff out there about unicode
"width"

https://github.com/joshuarubin/wcwidth9

On Sun, Jan 28, 2018 at 10:55 AM, Alexander Burger 
wrote:

> Hi Michel,
>
> > "by looking at the first byte of a multibyte character, we can determine
> > the length of the character: If the first byte is between 0xC0 and 0xDF,
>
> This is correct, and this is handlen in many places inside the PicoLisp
> interpreter. Without this, the names of symbols could not be handled at
> all.
>
> The problem we have here, however, is how many position a character takes
> up on
> the *screen* when printed. There is no easy rule, I think. Even Kana exist
> in
> two width variations.
>
> ♪♫ Alex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


Re: Chinese input causes mess in the REPL

2018-01-28 Thread Michel Pelletier
I'm not an expert on this, but doing a little digging I see some links on
calculating utf-8 character sizes and it seems like a lookup table is not
necessary:

http://www.daemonology.net/blog/2008-06-05-faster-utf8-strlen.html

"by looking at the first byte of a multibyte character, we can determine
the length of the character: If the first byte is between 0xC0 and 0xDF,
the UTF-8 character has two bytes; if it is between 0xE0 and 0xEF, the
UTF-8 character has 3 bytes; and if it is 0xF0 and 0xFF, the UTF-8
character has 4 bytes."

On Sat, Jan 27, 2018 at 11:54 PM, Danilo Kordic 
wrote:
>
>   GNU Emacs can be used as a line editor.  Execute elisp expression
> ``(term "/absolute/path/to/pil")'' then activate `term-line-mode' with
> ``C-C C-j''.
>
>   Is this of any help?  How much does it count :) ?
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Differences of Stack and List data structures

2017-10-01 Thread Michel Pelletier
This is not a PicoLisp specific question.  I'm sure many of us here want to
encourage your interest in general programming concepts, but there are much
better venues for you to get answers to questions like this.  For example,
on youtube the Kahn Academy has excellent tutorials on programming, while
most of them are in the Python programming language, the concepts are
entirely general and translate to all languages, including all lisps.  You
will likely find many lisp tutorials there as well.  As for stacks vs
lists, wikipedia has excellent articles on both:

https://en.wikipedia.org/wiki/Stack_(abstract_data_type)

https://en.wikipedia.org/wiki/Linked_list

You will get detailed responses to your questions on this list if you
constrain them to topics related to PicoLisp.

-Michel

On Sun, Oct 1, 2017 at 5:49 AM, stayfirefo...@outlook.com <
stayfirefo...@outlook.com> wrote:

>
>
>
>
> Sent from Mail  for
> Windows 10
>
> Hello everyone,
>
> What are all differences of stack and list data structures?
>


Re: List graph library?

2017-04-05 Thread Michel Pelletier
It would be pretty easy to generate 'dot' from picolisp:

https://en.wikipedia.org/wiki/DOT_(graph_description_language)

On Wed, Apr 5, 2017 at 5:56 PM, Christopher Howard <
christopher.how...@qlfiles.net> wrote:

> Hi. Does somebody have a FOSS library handy for graphing a picolisp list
> (like, hierarchically)? Say, SVG format or something? I can't imagine
> somebody else hasn't already tackled that problem...
>
> --
> https://qlfiles.net
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


Re: 'native' and pointers to pointers

2017-04-02 Thread Michel Pelletier
Thanks for the explanation Erik!  Sorry I misspelled your name. :)

On Sun, Apr 2, 2017 at 12:11 PM, Erik Gustafson 
wrote:

> Michel,
>
> Here's a link to exactly what you need:
>
> https://github.com/michelp/0pl/blob/master/zmq/zctx.l#L5
>
>
> I totally forgot about 0pl - That's it! Thanks for the quick response.
>
>
> a thread in the archives where Alexander explains it to me...
>
>
> I wasn't able to find it, but here's my attempt:
>
> Passing a pointer reference to 'native' is similar to the integer
> reference example found here: https://software-labde/
> doc/native.html#structArg
> .
>
> It becomes clearer when we think of a reference (a pointer) to a pointer
> instead as a buffer of 8 bytes - sizeof(*ptr) | sizeof(long) - that
> contains a pointer.
>
> We can pass this buffer to 'native' with:
>
>(list NIL (8) (cons Ptr 8))
>
> 'native' then receives something like:
>
>(NIL (8) (35680432 . 8))
>
> In English, I'd read this as "a buffer of 8 bytes - that we won't need to
> reference again (hence NIL) - initialized to contain our pointer, literally
> 'long 35680432' in C."
>
> That's a mouthful. Let's create a naive little helper function so we don't
> have to think about it anymore:
>
>(de  (P) (list NIL (8) (cons P 8)))
>
> A bit more intuitive now:
>
>: (setq *N (native "libzyre.so" "zyre_create" 'N "node"))
>-> 36274819
>: (setq *N (native "libzyre.so" "zyre_destroy" NIL ( *N)))
>-> NIL
>
> Look how nicely '' pairs with the global variable naming convention ;)
> not that I'd ever recommend a global variable for each node on a network...
>
> Corrections/clarifications encouraged!
>
> Cheers,
> Erik
>
>


Re: 'native' and pointers to pointers

2017-04-02 Thread Michel Pelletier
Hi Eric,

Here's a link to exactly what you need:

https://github.com/michelp/0pl/blob/master/zmq/zctx.l#L5

There's a thread in the archives where Alexander explains it to me,
unfortunately it's been a while I don't remember all the details myself...

-Michel

On Sun, Apr 2, 2017 at 10:00 AM, Erik Gustafson 
wrote:

> Hi list,
>
> I'm playing with PicoLisp's 'native' functionality and
> https://github.com/zeromq/zyre Most everything works as expected. Trivial
> example:
>
>: (setq Node (native "libzyre.so" "zyre_new" 'N "Node"))
>-> 9322320  # Node set to pointer
>: (native "libzyre.so" "zyre_uuid" 'S Node)
>-> "44536C1E..."  # uuid string
>
> Perfect. The trouble is with 'zyre_destroy'. The C function signature is,
>
>void zyre_destroy (zyre_t **self_p)
>
> In C code it would be called as,
>
>zyre_t *node = zyre_new("node");
>
>zyre_destroy();
>
> How would I do the same in PicoLisp (call 'native' with the equivalent of
> '')? The obviously incorrect,
>
>: (native "libzyre.so" "zyre_destroy" NIL Node)
>
> segfaults. As does,
>
>: (native [...] NIL (struct Node 'N))
>
> and
>
>: (native [...] NIL (car (struct Node '(N
>
> I think I need to do *something* with 'struct', but everything I've tried
> ends with a segfault.
>
> Note: In the Zyre header file the only mention of 'zyre_t' is,
>
>// Opaque class structures to allow forward references
>typedef struct _zyre_t zyre_t;
>
> so I'm not sure how to use 'struct' with it.
>
> Thanks,
> Erik
>


Re: Wiki search for 'NIL'

2016-12-27 Thread Michel Pelletier
Martin Porter keeps a list of common english stop words that is frequently
used to improve search results:

http://snowball.tartarus.org/algorithms/english/stop.txt

On Tue, Dec 27, 2016 at 6:31 AM, Erik Gustafson 
wrote:

> Hi Alex,
>
> As we see, it indexes only words which have a length of 4 characters or
> more.
>
> The reason is to decrease the total index size (which may in fact not be
> critical) and to avoid noise like "a", "the" and "and". This function
> could be
> made more intelligent.
>
>
> Ahh, that makes sense. I may or may not play around with some changes on a
> local copy. Might save a newcomer or two some time down the road; not
> exactly mission critical though.
>
>


Re: Backspace across wrapped line

2016-03-05 Thread Michel Pelletier
There's also the option of using an optional third party library like
https://github.com/antirez/linenoise

On Sat, Mar 5, 2016 at 9:02 AM, Jakob Eriksson 
wrote:

> A shotgun approach would be to create a screen editor of sorts,
> with a repl in it. That is probably overkill.
>
>
>
> On 05/03/16 16:18, Alexander Burger wrote:
> > Hi all,
> >
> > since early versions of PicoLisp I have a problem with the behavior of
> > terminals.
> >
> > It concerns the REPL line editor in debug mode, the way how a backspace
> > behaves across a wrapped line.
> >
> >
> > To move backwards in the line, the line editor sends a Ctrl-H to the
> > terminal. This happens not only explicitly (e.g. when the user types 'h'
> > in vi-mode), but also implicitly when the line is refreshed.
> >
> > The problem arises when the line gets longer than the number of columns

Re: A Unit Testing library for PicoLisp

2015-03-18 Thread Michel Pelletier
Dude you're on fire!

On Wed, Mar 18, 2015 at 8:21 AM, Alexander Williams a...@unscramble.co.jp
wrote:

 Hi list,

 I've written a small unit testing library/framework for testing PicoLisp
 code.

 It's extremely simple but produces somewhat decent output.

   https://github.com/aw/picolisp-unit

 I've already included this library in the picolisp-bcrypt library, and
 written tests for it as well:

 https://travis-ci.org/aw/picolisp-bcrypt

 The library includes a few types of assertions, but I still have some
 others to add, including refute and some other things.

 Please let me know your comments/suggestions

 Thanks!



Re: A PicoLisp native library tutorial

2015-03-03 Thread Michel Pelletier
Awesome!

On Tue, Mar 3, 2015 at 11:49 AM, Jakob Eriksson ja...@aurorasystems.eu
wrote:

 Yep.

 Definitely interesting.




 On 03/03/15 18:50, Joe Bogner wrote:
  Nicely done. Thanks for sharing
 
  On Tue, Mar 3, 2015 at 12:16 PM, Henrik Sarvell hsarv...@gmail.com
 wrote:
 
  Nice!
 
  On Tue, Mar 3, 2015 at 5:36 PM, Alexander Williams
  a...@unscramble.co.jp wrote:
  Hi list,
 
  Some of you might know me from IRC @aw-Unscramble.
 
  I've written my first PicoLisp library, a native C binding for Nanomsg
  (picolisp-nanomsg) - as an experiment for myself to learn this
 language.
 
  In doing so, I ran into a few difficulties (mostly noob stuff) but
  Regenaxer
  has been very helpful and patient.
 
  I also wrote a tutorial explaining the code, to help other newbies
  understand some useful features of PicoLisp:
 
https://github.com/aw/picolisp-nanomsg/blob/master/EXPLAIN.md
 
  And of course, the library: https://github.com/aw/picolisp-nanomsg
 
 
  Thanks!
 
  --
  UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 

 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: A pragmatic solution to using arrays in picolisp

2015-02-17 Thread Michel Pelletier
Arrays are very useful for numeric computing over linked lists.  Contiguous
blocks of linear memory are much more efficient, improving on numeric
density, cache occupancy, and being able to take advantage of specific CPU
vector instructions.  For GPU based computing, contiguous arrays are
essential and linked lists are useless, they must be scanned in linear time
and no warp-level parallelization is possible.

I don't think it's necessary to add arrays to the core language however,
given a sufficiently featured array library, picolisp's FFI interface can
be used to provide a nice abstraction above it.  This is similar to how
numeric arrays are used in Python with the numpy package.  Functions are
provided to copy data into and out of arrays from lists, dictionaries, or
files, and the actual operations on the arrays are carried out by a native
C library (and often third party libraries like blas/lapack).  The arrays
themselves are just opaque pointers to corrected sized and memory ordered
malloc'ed regions.

Googling 'C array library' returns many interesting hits.  Judy arrays also
look very interesting: http://judy.sourceforge.net/

-Michel

On Tue, Feb 17, 2015 at 9:04 AM, Enrique Sánchez petenr...@gmail.com
wrote:

  But if you have such a redundant structure, where the array elements
  point into the list, you have a large overhead to build both the array
  and the list.

 I think that building trees take more overhead than executing a
 malloc and building a linear list. (And probably more cons cells).

  You can't do any changes (cons, insert, delete, reverse)
  without rebuilding the array. And - as before - you have to keep track
  of your arrays to know when to dispose them.

 There's no point in creating array helpers for small lists elements.
 These helpers are only useful for large lists.

 Most of us always use these big arrays as global, static (in the C
 sense), created at the beginning of a program, living during the whole
 lifetime of a program, and being disposed of manually at the end of
 the program, or automatically by the system at program end.  During
 their life, these arrays don't grow, the structure remains the same,
 because they have the nature of an array.

 Of course I could use the allocation and disposing of small arrays at
 many points in the source code with this system, as you fear, like C
 and C++ programmers do. But that is hell, I would not do that.  They
 do that because they don't have other means.

 So the allocation and disposing using malloc() and free(), are only
 made typically for a pair of big arrays at two well known points in
 the source code, and that's it.

 The following is a typical program showing the use of array helpers:

 (setq *Ram   (array (readFile 65536 ram.bin))  # memory array
 *PC0   # Program pointer
 *SP16384   # Stack pointer
 *Reg1 0  *Reg2 0  *Reg3 0  # general registers
 *Run   T )

 (while *Run
(setq *P (nth: *Ram *PC)) # random access
(execute *P) )

 [... here would be all the main code ...]

 (dispose *Ram) # optional
 (bye)


 For this kind of program, using trees to emulate raw memory array
 functionality seems convoluted, and I guess at least 10 times slower.
 Convoluted because of the emulation of a more primitive structure by
 means of a more complex one.

 The most important data structure in Picolisp, the cons cell, is
 nothing more than a array element, addressable by a pointer, that is
 just an array index. If I want to use Picolisp to do exploratory
 programming of computer interpreters, then having arrays seems
 natural.

  I'm still not convinced at all that accessing list elements by a numeric
  index is really needed, or at least justifies the effort. The mentioned
  'hash' mechanism is alread there, in constructs like the built-in
  'cache' function (see also the answer by Denis Fourt).

 If you consider that for building interpreters, emulating raw memory
 indexes with trees is appropiate, then I don't think so. I see it
 half way as convoluted as clogging the symbol table with symbols like
 'M1, 'M2 ... for doing that.

 Or may be you consider that trees are not appropiate for that kind of
 application, as is my opinion, and your solution is to resort to
 another computer language, as C, for doing that kind of programming.
 In this case I would understand your choice. I would like to be able
 to do that kind of low level programming in picolisp.

 The implementation effort would be about 20 lines of code.


 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Performance Observation

2014-09-25 Thread Michel Pelletier
Can you provide the code?
On Sep 25, 2014 4:19 PM, Mark Probert probe...@gmail.com wrote:


 Hi.

 I have been having a lot of fun learning picoLisp.  Thank you Alex for
 this gem!

 As part of my learning, I converted a simple Ruby program I had into
 plisp and thought I would share the results.

 The program (namegen) slurps in two files -- one of firstnames with
 attributes, the other of lastnames -- then produces a random list of
 First Last pairs to stdout.  The data table sizes are

 $ ./namegen.l -i
 Database Size:
Surnames   = 240471
Firstnames = 23405

 Here are results of running the ruby and plisp versions (same machine i7
 running 64b Fedora fc19 with lots of memory)

 # ruby version (ruby 2.0.0p353)

namegen.rb -i   0.22s user 0.01s system 99% cpu 0.233 total
namegen.rb -n 100.25s user 0.01s system 99% cpu 0.266 total
namegen.rb -n 100   0.25s user 0.01s system 99% cpu 0.262 total
namegen.rb -n 1000  0.26s user 0.01s system 92% cpu 0.289 total

 # picolisp version  (picolisp 3.1.7.0)

namegen.l -i0.16s user 0.01s system 99% cpu 0.171 total
namegen.l -n 10 0.16s user 0.01s system 99% cpu 0.174 total
namegen.l -n 1000.22s user 0.01s system 99% cpu 0.230 total
namegen.l -n 1000   0.69s user 0.01s system 99% cpu 0.702 total

 The interesting thing is that the ruby version seems constant over the
 number of pairs generated.  I suspect that might be how I/O is handled.
 The (-i) version just does the data reading, the others read and write.
 Not a problem, just interesting.

 Fun stuff.

  .. m.
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: try picolisp

2014-08-28 Thread Michel Pelletier
The 64 bit version of picolisp can be ported to any machine.  There
is an existing emulator that generates C code, another emulator that
generated Javascript would be cool!

-Michel

On Thu, Aug 28, 2014 at 10:41 AM, Mike Pechkin mike.pech...@gmail.com wrote:
 hi,

 Is it hard to implement minimalist version of minipicolisp in browser ?
 Like http://tryclj.com/ ?

 Mike

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: NIL and

2014-08-23 Thread Michel Pelletier
On Sat, Aug 23, 2014 at 11:56 AM, Christophe Gragnic
christophegrag...@gmail.com wrote:
 On Sat, Aug 23, 2014 at 3:13 PM, Alexander Burger a...@software-lab.de 
 wrote:
 Is there somewhere some info about  being NIL?
http://software-lab.de/doc/ref.html#nilSym
http://software-lab.de/doc/ref.html#nilSym-io

 Thanks. I knew about this links, I just wanted to know why.

 The language I'm trying to embed in PicoLisp would love to have
  and NIL different !

 Why? I believe this is a wonderful feature! A lot of PicoLisp's
 expressive power is a result of this universality of NIL.

 This kind of answers my question !
 I understand this being a power, a kind of polymorphism, like
 in Python where the boolean value of , [],… is False.
 But in the language I design, I'd like to have separate values
 for  and NIL. In fact, NIL doesn't exists at all!

 I'm afraid this is a big problem for me.
 Maybe I'll try with a special symbol…

If NIL doesn't exist at all, then why do you need to expose it?  If
you language exposes lists or strings then empty ones carry the same
meaning.

-Michel



 chri

 --

 http://profgra.org/lycee/ (site pro)
 http://delicious.com/profgraorg (liens, favoris)
 https://twitter.com/profgraorg
 http://microalg.info
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Subscribe

2013-04-25 Thread Michel Pelletier