Hi all,
as the usefulness of 'symbols' namespaces increased somewhat with the
introduction of Transient Namespaces (see my previous mail, and the
article at http://picolisp.com/5000/!wiki?transientNamespaces), I've
also added 'symbols' and related functions to Ersatz PicoLisp.
It is available in
Hi Alex,
>> Also, as we discussed on IRC, it would be nice to have the namespace
>> name displayed in the repl prompt, e.g. via customizable prompt
>> function as you suggested.
>
> I would suggest a new global variable '*Prompt', which may hold an
> 'exe', so that
>
>(setq *Prompt '(symbols))
Hi Alex,
>> Also, as we discussed on IRC, it would be nice to have the namespace
>> name displayed in the repl prompt, e.g. via customizable prompt
>> function as you suggested.
>
> I would suggest a new global variable '*Prompt', which may hold an
> 'exe', so that
>
>(setq *Prompt '(symbols))
On Tue, Oct 11, 2011 at 12:08:10PM +0200, Alexander Burger wrote:
> I would suggest a new global variable '*Prompt', which may hold an
> 'exe', so that
>
>(setq *Prompt '(symbols))
>
> will result in a prompts
>
>pico:
>
> The ':' is supplied automatically, and - as before - changes to
Hi Tomas,
> Also, as we discussed on IRC, it would be nice to have the namespace
> name displayed in the repl prompt, e.g. via customizable prompt
> function as you suggested.
Oops, right. Forgot about that.
I would suggest a new global variable '*Prompt', which may hold an
'exe', so that
(
Hi Alex,
>(setq x st1)
>(setq x~sym1 5)
>(print sym1 x~sym1 st1~sym1) # => NIL 5 5
great, it does what I was after!
>> How can I create a new empty symbol table?
>
> This is easy. Just initialize it with an empty cons pair:
>
>(setq st1 (cons))
>
> However, I just didn't want to
Hi all,
please note that I released a slight modification of the namespace
support: The 'load' function will preserve the current namespace, even
if it is changed by 'symbols' while loading a file.
The reasons can be seen best in the example from the previous d
On Mon, Sep 19, 2011 at 07:56:42PM +0200, Tomas Hlavaty wrote:
> >2. importing a symbol from another namespace (with 'intern')
>
> Renaming a symbol is not interesting. Importing maybe is, to a certain
> point.
Now I added an 'import' function, a simple frontend to 'intern'. With
that, we ca
It solves the long function name problem and due to class naming conventions
it improves the global namespace problem quite a bit.
The long function name solution solves the the global namespace problem
completely but is imo not a good solution as it can easily become absurd.
On Tue, Sep 20, 201
Hi Tomas,
> Why to add this feature to picolisp if it is not supposed to be used?
Well, I didn't say it is not supposed to be used. People might indeed
use it.
> >> One of the most important operations on namespaces should be creating
> >> a local name (alias) for it.
> ...
> You'd need to sepa
Hi Henrik,
>>> (func> '+Kadabra arg1 arg2)
>>>
>>> is shorter than:
>>>
>>> (foo.bar.blabla.abra.kadabra.func arg1 arg2)
>> no, it's similar to (Kadabra.func arg1 arg2).
>>
>> (func> '+Foo.bar.blabla.abra.kadabra arg1 arg2) is similar to
>> (foo.bar.blabla.abra.kadabra.func arg1 arg2).
> My exa
My example implied that +Kadabra is a sublass of a sublcass and so on up to
+Foo.
On Tue, Sep 20, 2011 at 12:56 AM, Tomas Hlavaty wrote:
> Hi Alex,
>
> >> Personally I am not a fan of namespaces in picolisp.
> >
> > Yes. As you know, I am neither.
>
> at least we agree on this;-)
>
> > However,
Hi Alex,
>> Personally I am not a fan of namespaces in picolisp.
>
> Yes. As you know, I am neither.
at least we agree on this;-)
> However, the current implementation won't do any harm, as long as it
> is not actually used (and I won't probably use it ;-)
Why to add this feature to picolisp if
> (func> '+Kadabra arg1 arg2)
>
> is shorter than:
>
> (foo.bar.blabla.abra.kadabra.func arg1 arg2)
no, it's similar to (Kadabra.func arg1 arg2).
(func> '+Foo.bar.blabla.abra.kadabra arg1 arg2) is similar to
(foo.bar.blabla.abra.kadabra.func arg1 arg2).
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:pi
Henrik Sarvell
writes:
> I can understand both your arguments Thorsten but in the end there
> must've been a reason why you found PicoLisp interesting enough that
> you wanted to try it out as opposed to using elisp/common lisp for
> everything.
> Perhaps it was the brevity and clarity of syntax
I can understand both your arguments Thorsten but in the end there must've
been a reason why you found PicoLisp interesting enough that you wanted to
try it out as opposed to using elisp/common lisp for everything.
Perhaps it was the brevity and clarity of syntax, the minimalism?
I can tell you t
Jakob Eriksson writes:
> On Mon, Sep 19, 2011 at 02:51:32PM +0700, Henrik Sarvell wrote:
>> Having to write the full name all the time could easily become
>> comical, as in my above Clojure example. This is also one of the
>> reasons I have leaned towards
>
> +1
>
> Imagine all the rants which co
On Mon, Sep 19, 2011 at 02:51:32PM +0700, Henrik Sarvell wrote:
> Having to write the full name all the time could easily become comical, as in
> my above Clojure example. This is also one of the reasons I have leaned
> towards
+1
Imagine all the rants which could be made about code full of both
> Importing symbol from another namespace can be done with
>
> (intern 'myNames~Foo)
> -> Foo
>
> This will make the symbol 'Foo' from 'myNames' available as an internal
> symbol in the current namespace.
>
This is imo a must have feature, it has to be up to the programmer to avoid
"clashes" a
Hi Thorsten,
> one question with regards to this topic:
> what would be the advantage of namespaces in Picolisp over
> namingconventions like in Emacs Lisp?
Right. Not much.
> 'gnus-function-name' for all functions in gnus library
> 'dired-function-name' for all functions in dired library etc
Hi Tomas,
> Personally I am not a fan of namespaces in picolisp.
Yes. As you know, I am neither.
However, the current implementation won't do any harm, as long as it is
not actually used (and I won't probably use it ;-)
It is a simple extension of the general principles underlying PicoLisp
symb
Hi List,
one question with regards to this topic:
what would be the advantage of namespaces in Picolisp over
namingconventions like in Emacs Lisp?
'gnus-function-name' for all functions in gnus library
'dired-function-name' for all functions in dired library etc
That seems to work quite well i
Hi Alex,
>> for namespaces convenient. Scheme implementations provide an import
>> statement that let's you include symbols from one namespace into your
>> current one. This is not yet exciting but you can manipulate the
>> symbols during this import:
>>
>> - prefixing them
>> - renaming them
>>
Hi Henrik,
> As far as I can tell this makes the (context) thing you implemented before
> pretty redundant or is it worth keeping?
Yes, I would say we forget about that one.
It was a completely different concepts. It didn't implement symbol
namespaces (all symbols were still in the single global
Hi Christian,
> for namespaces convenient. Scheme implementations provide an import
> statement that let's you include symbols from one namespace into
> your current one. This is not yet exciting but you can manipulate
> the symbols during this import:
>
> - prefixing them
> - renaming them
> - f
As far as I can tell this makes the (context) thing you implemented before
pretty redundant or is it worth keeping?
On Fri, Sep 16, 2011 at 6:39 PM, Alexander Burger wrote:
> Hi all,
>
> from time to time, the issue of symbol namespaces (or the lack of them)
> in PicoLisp is brought up again.
>
* Alexander Burger [110916 13:45]:
> Any opinions?
Awesome work! Comming from scheme I find the manipulating functions
for namespaces convenient. Scheme implementations provide an import
statement that let's you include symbols from one namespace into
your current one. This is not yet exciting bu
Hi all,
from time to time, the issue of symbol namespaces (or the lack of them)
in PicoLisp is brought up again.
Personally, I think that namespaces (that is, different sets of interned
symbols in different contexts) may confuse more than they do really
help.
But with transient symbols we do alr
28 matches
Mail list logo
