<beneroth>
Regenaxer, exactly. now here I even use (intern) on them before switching into the namespace and defining the class
<Regenaxer>
Cool, thanks. I take a look later, busy atm
<beneroth>
this is my main issue with namespacing and database stuff.
<Regenaxer>
hmm, intern is not useful I believe
<beneroth>
it can work, there are legitimate use cases.. but the potential to produce a chaos by accident is just too large
<Regenaxer>
(local) is the way to go
<beneroth>
Regenaxer, intern the property names on 'pico
<beneroth>
hm righzt
<Regenaxer>
yes, but I never call intern for that
<Regenaxer>
just pico~word
orivej has quit [Ping timeout: 264 seconds]
<beneroth>
right, local would be better
orivej has joined #picolisp
<beneroth>
so you would recommend using pico~nm for the property name?
<Regenaxer>
Depends
<Regenaxer>
Normally you select the proper search order
<Regenaxer>
then it does not matter *where* propery keys reside
<Regenaxer>
anyway, sorry, later ;)
<beneroth>
my use case here is about a normal class, not an +Entity. properties are set by the caller as arguments to (new), or by default within the namespaced code. I need to ensure that the property names stay in the callers namespace even when they're set by the default setters within the namespace
<beneroth>
Regenaxer, np, mahlzeit :-)
<tankf33der>
remember
<tankf33der>
i would get copy and append functions for pil21
orivej has quit [Ping timeout: 256 seconds]
<beneroth>
Regenaxer, now I do (symbols 'foo 'pico) (local) (+Bar) (class +Bar) (symbols 'pico 'foo) (dm T @ ...)
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
<beneroth>
afk
<Regenaxer>
ret
<Regenaxer>
I see! I would always set for the class currently being defined
<Regenaxer>
the namespace as the first one
<Regenaxer>
thus NOT (symbols 'pico 'foo) (dm T @ ...)
<Regenaxer>
this gives chaos
<Regenaxer>
Usually propery keys don't care in which namespace they reside
<Regenaxer>
I care only about symbols being modified (def, value, properties)
<Regenaxer>
tankf33der, ok, more list functions
<Regenaxer>
But the basics are not straight yet
<Regenaxer>
these worry me more
<Regenaxer>
and if something turns out to be fundamentally wrong, more user-level functions need to be rewritten. That's why I'm reluctant to implement too much stuff early which is clear to work anyway
<tankf33der>
i see. np.
<Regenaxer>
hmm, the issue in the link about readline/SIGALRM seems to address another issue
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<Regenaxer>
Ha! Found it in the readline docs :)
<Regenaxer>
Needs rl_catch_signals = 0;
<Regenaxer>
Works better, but not sure if it is the right way
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
<beneroth>
Regenaxer, ah, so you had to configure readline to not catch your signals
<Regenaxer>
yes, and call some init / deinit functions
<Regenaxer>
still does not behave 100 % correct
<beneroth>
makes me wonder why this is not the default... so either the signals are usually used by readline, or the programmers were not pragmatic
<Regenaxer>
It is documented
<Regenaxer>
readline installs its own handlers
<Regenaxer>
but resets to the program's ones when getting a signal
<Regenaxer>
BUT
<beneroth>
Regenaxer, I like to namespace the class, but use it outside of the namespace. So just to prevent shadowing/clashes on the class name. But as I work outside of the namespace with it, it's a bit impractical if I cannot get properties because their names are namespaced too...
<Regenaxer>
I call waitFd before that
<beneroth>
ah
<Regenaxer>
and this seems to be before readline resets
<Regenaxer>
it is all confusing
<Regenaxer>
hmm, as ever you try crazy things ;)
<Regenaxer>
But the principle is simple
<beneroth>
¯\_(ツ)_/¯
<Regenaxer>
whatever the reader sees
<beneroth>
yes, but it's only simple as long as the reader/reading context is always the same :)
<Regenaxer>
I think it is important that the search order is the same while the program rons
<Regenaxer>
runs
<beneroth>
absolutely. but that kinda.. reduces the practical flexibility of namespaces a bit
<Regenaxer>
not reader/reading context per see, but the search order
<beneroth>
T
<Regenaxer>
It must be the same in a given context
<Regenaxer>
I switch that context, eg in PilBox
<beneroth>
well there are also implicit assumptions about which global symbols exist in the current namespace, and even others in the search order
<Regenaxer>
but for a given situation it must stay the same
<beneroth>
T
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
<Regenaxer>
No assumptions, except what is (local)
<Regenaxer>
property keys don't care
<Regenaxer>
if you dont change the search order between reading and executing
<beneroth>
property keys must be the same symbols while setting and getting them
<beneroth>
aye
<beneroth>
if
<Regenaxer>
exactly
<Regenaxer>
beause get etc use '=='
<beneroth>
I grokked it, I just still struggle with the practical application for more crazier use cases than your disciplined limited ones
<Regenaxer>
yeah, you need always discipline
<beneroth>
I kinda like to have a prefix, same as foo-bar, but foo being in a different logical scope than bar so it can be used to reduce shadowing/clashes. that is kinda the implementation of most mainstream namespacing systems (which comes without many features/flexibility your one has)
<Regenaxer>
Better be careful. Use namespaces to keep things *private*
<beneroth>
T
<beneroth>
so just use it as transient scoping spanning multiple files
<Regenaxer>
ok, good that you do such research
<beneroth>
do not use it to group global symbols to prevent shadowing/clashing
<beneroth>
I should just use prefixes for that
<Regenaxer>
In my experience, I normally never need to use a nsp~ prefix
<beneroth>
which ofc comes with the disadvantage that too much symbols might end up in the long tree
<beneroth>
yes, I totally understand
<beneroth>
the point is, I would like to actually use them
<Regenaxer>
Well, also no problem
<beneroth>
but that is not how it is intended
<Regenaxer>
in fact, pil21/src/lib/llvm.l uses pico~ and llvm~ heavily
<Regenaxer>
but this is a specail case
<beneroth>
and still the most symbols are only used from within their namespace, right?
<beneroth>
not much cross-namespace stuff
<Regenaxer>
In llvm it is
<beneroth>
ok
<Regenaxer>
it builds a stand-alone namespace
<Regenaxer>
which is cut off when the compiler runs
<Regenaxer>
So I'm not sure what is the best
<Regenaxer>
We need conventions
<beneroth>
T
<beneroth>
nothing wrong about your system, all good
<beneroth>
it's just.. it's more like named transient scopes, in a way, okay if I word it like that?
<Regenaxer>
yes, but for special use cases we need other conventions perhaps
<beneroth>
T
<beneroth>
as always: it depends
<Regenaxer>
It is more than named transient scopes
<Regenaxer>
cause they are not gone
<Regenaxer>
reactivated when setting the order
<beneroth>
my use case: having an ever-growing space of global symbols. to prevent shadowing/clashes I like to group them, so only clashes within groups and clashes of group identifiers have to be cared about
<beneroth>
Regenaxer, T, through transient scope are also not gone, as long as you have a reference into it
<Regenaxer>
So is each group of globals in its namespace?
<Regenaxer>
no, for the reader they are gone
<beneroth>
T
<Regenaxer>
the symbols
<beneroth>
are you familiar with C++ namespaces?
<Regenaxer>
no
<beneroth>
ok
<Regenaxer>
But they are about *definitions*, not symbols, right?
<beneroth>
right!
<beneroth>
exactly right, that is the essence
<Regenaxer>
In pil people confuse this with the definitions
<beneroth>
absolutely!
<beneroth>
exactly!
<Regenaxer>
This is the unusual thing in Pico(Lisp)
<beneroth>
picolisp namespacing is not about separation of definitions
<beneroth>
T
<Regenaxer>
You deal with symbols
<beneroth>
in a way there is no definitions
<beneroth>
(no static ones)
<Regenaxer>
yeah
<beneroth>
but how to do when you want to separate definitions?
<Regenaxer>
the definitios are stuck in the symbols
<beneroth>
the symbols are just a named reference to a definition
<Regenaxer>
yes, but also more
<beneroth>
(de foo () (prinl "hello"))
<beneroth>
foo is not the function
<Regenaxer>
T
<beneroth>
foo is a named reference to the function '(() (prinl "hello"))
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
<beneroth>
or even more detailed, foo is a symbol with the value pointing to (= being) the function definition
<Regenaxer>
T
<beneroth>
in most languages, foo IS the function
<beneroth>
or more detailed, foo combined with the argument list is the primary key on the virtual function table
<Regenaxer>
yes, foo is the name of the location
<beneroth>
T
<Regenaxer>
A symbol is a further inderection
<beneroth>
non-lisps: the list of functions and the names which bind to them is fixed, static, unchangeable
<beneroth>
lisp: dynamic and changeable
<Regenaxer>
We have family meeting, so I must join again ;)
<beneroth>
okay, happy family meeting :)
<beneroth>
I ponder some more
<Regenaxer>
thanks :)
<Regenaxer>
good!
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #picolisp
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #picolisp
<Regenaxer>
beneroth, btw, I just remember that I introduce d a new function 'export' in pil21
<Regenaxer>
analog to 'local'
<Regenaxer>
It searches and creates the symbols in the *second* namespace in the search order
<Regenaxer>
Let's see if it is useful. I use it in pil21/lib/pilog.l
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<beneroth>
Regenaxer, interesting
<beneroth>
why second, and not arbitrary (by argument) ?
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
<Regenaxer>
Yes, could also be
<Regenaxer>
Makes it a bit more confusing
<Regenaxer>
Also, it could more easily be dynamic
<Regenaxer>
(apply symbols (symbols) 'foo)
<Regenaxer>
so it exports symbols into the "current"
<beneroth>
either focus on power/flexibility, or on reducing confusions
<beneroth>
ideally both, but so far namespaces are already pretty confusing :P
<beneroth>
they're simple
<beneroth>
but involved
<Regenaxer>
indeed
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<Regenaxer>
It could be the optional namespace directly, right? (export pico)
<Regenaxer>
unevaluated is ok I think
<Regenaxer>
The default (export) would still work
<Regenaxer>
hmm, then better (export 'pico)
<Regenaxer>
evaluated
<beneroth>
yeah better
<beneroth>
more flexible
<Regenaxer>
T
<Regenaxer>
I've added it to pil21
<Regenaxer>
Thanks for the idea!
<beneroth>
this is the primary software design principle I learned/got strongly enforced in by picolisp and your work:
<beneroth>
make the foremost to minimize adding any restriction in the software design which is not essential to the task/functionality at hand
<Regenaxer>
fully agree
<beneroth>
because a lot of non-re-usability is accidental / stems from ignorance/lack of care
<Regenaxer>
but the other criterion is simplicity
<beneroth>
T
<beneroth>
it's also the way to decide things
<beneroth>
same as occam's razor
<beneroth>
if in doubt, take the simpler route
<beneroth>
YAGNI
<Regenaxer>
T. In some way (symbols pico) is simpler than (symbols 'pico), but rather irrelevant
<Regenaxer>
oops
<beneroth>
the more simple the existing design is, the easier it is adaptable to future needs which most likely are not foreseeable the slightest, even when we like to trick us otherwise
<Regenaxer>
(export pico) I meant
<beneroth>
T
<beneroth>
but (export 'pico) is less restrictive than a fexpr, because it allows dynamic arguments without needing to resort to apply
<beneroth>
:)
<Regenaxer>
right
<Regenaxer>
on the other hand it is used only on top level
<beneroth>
of course the general case would be non-dynamic, so it poses the question if we want to pay the overhead in the general case for the special case
<beneroth>
the usual picolisp answer to this would be: no
<Regenaxer>
yep
razzy has joined #picolisp
<Regenaxer>
If it is useful, we can backport 'export' to pil64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
<beneroth>
it is kinda like (local) but from outside of the namespace, right?
<beneroth>
probably useful
<beneroth>
it sounds like the opposite of (import) which it isn't, though it could be used for that... right?
<Regenaxer>
It is intended for libraries which encapsulate some local symbols but expand into another
<Regenaxer>
The Pilog symbols are part of pico main system
<Regenaxer>
but lib/pilog.l uses a transient namespace to hide stuff
<Regenaxer>
and exports things into the pico base system
<beneroth>
I see
<Regenaxer>
lib.l *could* be so too, but not necessary
<Regenaxer>
(has not much private symbols probably)
<beneroth>
I'm not sure yet if it's good to put everything into namespaces we put in transient scopes before
<beneroth>
it's more transparent and offers more control...
<beneroth>
but yeah
<Regenaxer>
yes, still experimental
<Regenaxer>
still quite new
<beneroth>
the namespace system is very powerful, but good principles how to use them practically still need to be developed for more involved use cases
<Regenaxer>
yes
<Regenaxer>
Currently I'm also rewriting the GUI
<Regenaxer>
goes into a 'htm' namespace
<beneroth>
so.. you touch more or less everything :)
<Regenaxer>
yes, but the gui I need now
<beneroth>
yeah those stuff can be easily used with namespacing, simple use cases
<Regenaxer>
T
<beneroth>
I'm still a bit unsure about classes and namespaces
<beneroth>
can get confusingly complex pretty easily
<Regenaxer>
Check the PilBox apps
<Regenaxer>
some have DB and all have their own namespace
<beneroth>
yeah, but no crossing of namespaces, right? :)
<Regenaxer>
crossing how?
<beneroth>
code in one namespace working with code within multiple other namespaces, especially passing objects through multiple namespaces
<Regenaxer>
Why make it so involved?
<Regenaxer>
kiss ;)
<beneroth>
e.g. producing objects in one namespace, handing it over to another namespace to work on it
<Regenaxer>
yes, why so complicated?
<Regenaxer>
Where is that useful?
<Regenaxer>
As I said above, changing search order in between is not a good idea
<beneroth>
to split code thematically into namespaces
<beneroth>
T
<beneroth>
I don't disagree the slightest
<beneroth>
I'm still figuring out if what I try in that space is wrong, or if the how I do it is wrong
<Regenaxer>
good
<beneroth>
the greater point is: if its possible, some people will do it and be confused by it
<beneroth>
so some documentation and guidelines would be good to have, eventually
<Regenaxer>
yes, conventions
<beneroth>
T
<Regenaxer>
We could discuss this in PilCon meetings
<beneroth>
while it is impossible to enumerate all stupid ideas, it should possible to set up some guidance which makes it easy into which territory an idea/use case falls
<beneroth>
T
<Regenaxer>
but except us two nobody understands pil namespaces ;)
<Regenaxer>
perhaps aw-
<beneroth>
aye :/
<beneroth>
so either it will remain a niche, or some tools (be it documentation, be it restrictions of their power in the implementation) will be needed to eventually make them properly understood and practical usable
<Regenaxer>
right
<Regenaxer>
Let's wait for pil21, it will come with namespaces out of the box
<beneroth>
your usage of them in llvm will be an interesting test bed :)
<beneroth>
T
<Regenaxer>
ok, must family again ;)
<beneroth>
and the exploratory work you do with namespaces and pil21 already produces new insights, e.g. (export) :)