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))
will
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))
will
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 support
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
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 '!' in
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 discussion
with Tomas:
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 can
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,
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
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 as it is
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
Jakob Eriksson ja...@vmlinux.org 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
Henrik Sarvell hsarv...@gmail.com
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
(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:
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
- filtering out
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
-
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
17 matches
Mail list logo
