<Seteeri>
I'm trying to understand why this leads to the sym being redefined: (symbols 'abc 'pico) (symbols 'pico) (symbols '(abc) (de rd ()))
<Seteeri>
I thought symbols with a one-item list (not pico) would cause rd not to be found
<beneroth>
use (locale)
<beneroth>
it is found in the other namespace
<beneroth>
and you need to have the 'pico namespace in the search, otherwise (de) is not defined
<beneroth>
use (locale) to intern the 'rd symbol in the current namespace, then that one is used instead of searched for the symbol, ending up using the existing one in the other namespace
Seteeri has quit [Remote host closed the connection]
<beneroth>
sorry, I meant ofc (local) (without e). (local) interns specifically in the current namespace, while (intern) (or implicit interning) is first searching for an existing one in all namespaces listed in (symbols) call
Seteeri has joined #picolisp
orivej_ has joined #picolisp
orivej has quit [Ping timeout: 276 seconds]
<Regenaxer>
Seteeri: The expression (symbols '(abc) (de rd ())) is *still read* in the old search order
<Regenaxer>
(symbols '(abc) (in File (read))) would make sense for example
<Regenaxer>
So here the 'rd' symbol is still that in 'pico'
<Regenaxer>
You could do: (symbols 'abc 'pico) (symbols 'pico) (de abc~rd ())
<Regenaxer>
yes, but the rules of read -> eval are the same
<Regenaxer>
First *read* something, in the context of a namespace
<Regenaxer>
then *eval* it
<Seteeri>
the string in the pastebin works correctly if it's in a file and loaded from the cli
<Regenaxer>
(for X (str "(symbols 'abc 'pico) is the same as (for W '(symbols ...)
<Regenaxer>
yes, then it is evaluated
<Regenaxer>
(str ) just returns the list
<Seteeri>
invokes the parser/reader
<Regenaxer>
ah, sorry
<Regenaxer>
the string is multi line
<Regenaxer>
did not check
<Regenaxer>
So you get the long expression
<Seteeri>
unless it's bc the internal repl fn reads/evals each expression instead of what I'm doing
<Seteeri>
read all data at once, then eval
<Regenaxer>
'str' is no repl
<Regenaxer>
a repl is 'load'
<Seteeri>
yes
<Regenaxer>
(load "-foo" "-bar" ...
<Seteeri>
in my example the reader will execute the read macro for ~
<Regenaxer>
right, str does not
<Seteeri>
however the previous code has not been executed so the namespace has not been created yet
<Regenaxer>
hmm
<Regenaxer>
or *does* 'str' obey read macros*
<Regenaxer>
I don't remember atm
<Seteeri>
it does
<Regenaxer>
ok
<Seteeri>
internally both call read0
<Regenaxer>
right
<Seteeri>
the solution would be to read/eval each expression I'm thinking
<Regenaxer>
I think your approach is not wrong
<Seteeri>
that way the first expression will create the namespace
<Regenaxer>
not sure atm what exactly goes wrong
<Seteeri>
i guess its unorthodox lol
<Regenaxer>
:)
<Regenaxer>
and lot of overhead
<Regenaxer>
Cause I assume you first build the string
<Regenaxer>
and then 'str' it
<Seteeri>
when str is called, the reader is invoked, which causes the macro ~ to be called. however since nothing has actually evaluated, the abc namespace does not exist so it throws a namespace error
<Seteeri>
which is proper behavior
<Regenaxer>
not sure about the full macro handling
<Regenaxer>
'any' return the *first* expression only
<Regenaxer>
'str' makes an implicit list
<Regenaxer>
without parens
<Seteeri>
any is (car (str ...))
<Regenaxer>
no
<Regenaxer>
parens
<Regenaxer>
: (str "a b c")
<Regenaxer>
-> (a b c)
<Regenaxer>
: (any "(a b c) (d e f)")
<Regenaxer>
-> (a b c)
<Seteeri>
(any "a b c") -> a
<Regenaxer>
yes, not useful here
<Seteeri>
(str "a b c") -> (a b c)
<Regenaxer>
"prog ..." :)
<Regenaxer>
try it!
<Seteeri>
I will try a few more things
<Regenaxer>
ok
<Regenaxer>
I cant write well
<Regenaxer>
outside at 4 C
<Regenaxer>
cold fingers ;)
<Seteeri>
haha
<Seteeri>
my original issue was when you do (symbols '(abc) ...) pico namespace should not be searched?
<Regenaxer>
yes, only abc is searched
<Seteeri>
if after creating the namespace, I do (symbols '(abc)), this will result in an empty sym table
<Seteeri>
and you would be trapped essentially
<Regenaxer>
yes
<Regenaxer>
'local' does that basically
<Seteeri>
my expectation was (symbols '(abc) ...) would do that same thing but return to the previous namespace (in this case default 'pico)
<Regenaxer>
yes, correct
<Regenaxer>
the problem was you did (de rd ...
<Seteeri>
but (symbols '(abc) ...) is still searching pico namespace
<Regenaxer>
*after* reading the expression
<Regenaxer>
yes
<Regenaxer>
but for (de rd ()) no search is done
<Regenaxer>
No reading
<Regenaxer>
(symbols '(abc) (de rd ()))
<Seteeri>
so is (symbols '(abc) rd) = (symbols '(abc pico) rd) ?
<Regenaxer>
it is just rd
<Regenaxer>
the symbol 'rd' is already read
<Seteeri>
mmm
<Seteeri>
thats why local uses (read)
<Regenaxer>
Exactly
<Seteeri>
since it would get interned when the fn is parsed
<Regenaxer>
it is a consequence of Read->Eval
<Regenaxer>
T
<Regenaxer>
The big lack is that the plio format cannot encode namespace specifiers
<Regenaxer>
Like print/read do with abc~rd
<Regenaxer>
Should think about an extension
<Seteeri>
mmm
<Seteeri>
any read macro can also be done with a normal fn I believe...
<Regenaxer>
true
<Regenaxer>
but ugly
<Seteeri>
it would be done in a previous stage like a preprocessor
<Regenaxer>
(list ...)
<Regenaxer>
T
<Seteeri>
and then you're back to C? :p
<Regenaxer>
Not really ;)
<Seteeri>
oh wait it'd still have access to the lisp env
<Regenaxer>
btw, (symbols '(abc)) "and you would be trapped"
<Regenaxer>
is not the case
<Regenaxer>
(symbols '(abc)) returns immediately
<Regenaxer>
and (symbols '(abc) (foo) (bar)) runs foo and bar
<Seteeri>
when I do (symbols '(abc)) on the repl, I can no longer access anything from pico (technically you could still call the fn ptrs to regain access)
<Regenaxer>
Ah, sorry, right. (symbols '(abc)) without body sets the namespace permanently
<Regenaxer>
Might be useful for a kiosk system ;)
<Seteeri>
yup
<Regenaxer>
though ^C lets one exit I believe
<Seteeri>
yes
Seteeri has quit [Remote host closed the connection]