Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - kazemori

Pages1 2
#1
newLISP newS /
April 25, 2005, 04:48:35 AM
Hello Lutz,



Since "kozoru" is a Japanese word, I'll offer you two more: "omedeto gozaimasu!"

(Congratulations!)



This is great news for you and the newLISP community.

(I suspect that the Kogut guy is really steaming about now ;-)



kazemori
#2
newLISP newS / newLISP manual
December 09, 2003, 04:45:48 PM
hello Lutz!



wow! you close your eyes for a few days and whammo! a host of corrections!



Lutz, if you have not already integrated the suggestions from Sammo and nigelbrown, i will take care of these. some of the suggestions are actually questions, which may require something more than an edit; for these items, please let me know what you are going to do...



as it is tuesday afternoon in vancouver, i will start with this batch of corrections tonight or wednesday (at the latest). i will use the 7.3.17 text, unless you already have something "fresh from the oven".



kazemori
#3
newLISP newS / RFC open on newLISP documentation
November 28, 2003, 02:41:37 PM
hello, everyone!



as some of you may know, i am helping out with the newLISP documentation. continuing from this weekend i will be correcting and updating the newLISP manual (and the newLISP-tk introduction) in preparation for the upcoming release (and ultimately, newLISP 8.0).



if you have any "typo's", "transpo's", and|or "pet-peeves" that you want Lutz and i to know about, please post them to this forum (Win32|Linux sub-forums). i will try to incorporate as much as possible (and with Lutz's approval, of course); however, producing a easy-to-read and consistent set of documentation is the priority for now.



i may be back with a poll on things like "built-in" vs. "builtin"... ;-)



thanks in advance for your kind cooperation!



kazemori
#4
newLISP newS / RFC open on newLISP documentation
November 28, 2003, 02:34:32 PM
-- deleted
#5
Anything else we might add? /
September 10, 2003, 12:50:06 PM
i think that Eddie has launched us off with a bang!



one of the things that we need to keep in mind is function ( or in this case primitive) interdependence.



most newLISP primitives are implemented internally via other primitives (a basic Lisp concept); it is easy to imagine, and perhaps even to produce, a dependency tree which illustrates this fact for newLISP.



if we assume as a design goal (as Lutz has stated previously) that it is desirable to keep newLISP:



(a) simple;

(b) transparent; and

(c) possessed of a small footprint -- both in static memory and within its runtime environment



then it follows that we can sort functions/primitives based on both their intrinsic usefulness and their resource dependencies.



take the newLISP primitive set!, which can easily be implemented externally: (setq set! setq). set! is presumably present only as a convenience to those who used it in a CL (or other) environment. this kind of "low-hanging fruit" begs for extraction from the newLISP executable, and re-implementation as a simple library file. i am sure that several other of the current primitives exist in this state.



in the case of deprecated primitives, perhaps a library could be created for these as well? if someone wants these (and can live with the possible implications for run-time performance), they need only modify their init.lsp file to load the "library of the damned" at start-up.



another category of primitives are the more esoteric, but nonetheless desirable, functions (advanced math, financial, statistical...). an argument can be made that these should be removed to a library, as well. a counter argument can be made that these functions benefit from being implemented internally (as fast C directives) and would be unacceptably slow if implemented in newLISP (the interpreted language).



again, i suggest that the dependency tree would be a useful tool in resolving this type of issue as well.



so, by all means, let's draw out our cutlery and sharpen our tools (assuming Lutz wants to prune newLISP ;-), but keep the following in mind:



"everything is connected to everything else"



evaluate and prioritize the associations, and then make good decisions, which we will not come to regret in later times. my two cents.



kazemori
#6
Anything else we might add? / Looking ahead to newLISP 8.0
September 10, 2003, 12:07:58 PM
EddieR posted the following thoughts in the recent thread on "threads"; i think this deserves promotion to its own thread.



(hope you don't mind, Eddie!)



EddieR writes:

======================================================



Since we have find and slice we could get rid of "member"



I've seen the (cond (bool1 exp1) (bool2 exp2) ....) vs (cond bool1 exp1 bool2 exp2 ...) debated in several books. Would it be bad to implement the if or the cond like (? bool1 exp1 bool2 exp2 ...). Maybe even get rid of either "cond" or the "if" altogether?



I know we've tossed around getting rid of starts-with and ends-with string functions, but, since you also provide for lists???



Why have "first" and "nth 0?"



Do we really need let? Or if we need let shouldn't we also have a let! that allows something like



code:

--------------------------------------------------------------------------------

(let! ((x 1) (y x)) (func ....))  where the second variable can use the value of the first variable?

--------------------------------------------------------------------------------



Isn't lookup the same as (rest (assoc ....



how about a reverse-assoc?



I know I'm drawing flames here, but, ...



Eddie



======================================================
#7
Anything else we might add? /
September 09, 2003, 06:14:46 PM
> Soo much to do ...



soo true !!!



i will be in touch soon  --  kazemori
#8
Anything else we might add? /
September 09, 2003, 03:17:25 PM
although i am a physicist by academic training, and started my professional life as a programmer, i have in fact achieved most of my private sector success in the field of sales & marketing. (hiss! boo!)



of course, it was always high-tech sales & marketing in silicon valley. (hiss! boo!)



many of the things you learn while working on the "dark side" have analogous structures in the world of programming, for example: key-value pairs -- dark side equivalent: feature-benefit pairs



implementing threads in newLISP will...



feature: add more capabilities to a versatile language

benefit: encourage more people to download newLISP



feature: justify a major revision number - newLISP 8.0

benefit: implementing a major revision will potentially allow you to implement / re-implement other projects that you may have held back on until now...



i am not remotely competent to help you with C coding; however, i am wizard writer. (yes, i know how to capitalize words ;-) my pen is at your disposal (for starters, i am already scrubbing the newLISP manual for typo's and other gotcha's. (i even scrubbed 50% of newlisp.c last night)



i also propose to retool the introductory paragraph that you have on the O'Reilly open source directory site. (read the Tcl text, and then read newLISP ;-) please let me know if this is okay with you!



evangelist-by-nature  --  kazemori
#9
Anything else we might add? /
September 09, 2003, 01:45:18 PM
Lutz -- no offense taken. i enjoy learning! (so please, teach away! ;-)



i used to say, "you will know that i am dead when a beautiful girl walks by and i do not even move to look at her". i think it is more succinct, more realistic (and even more pc) to say, "you will know that i am dead when i stop learning".



for what it is worth, i do think newLISP should have threads (light-weight, transparent threads). i think newLISP is an excellent Lisp and needs to be more widely adopted. threads will help in this regard, as much of the so-called competition come with threads "out-of-the-box" (e.g., Io, Lua, Ruby, etc.).



perceptions count for a lot in choosing among the various programming languages. just look at java: the language that took over the world through the power of marketing (not because of its intrinsic merits ;-).



kazemori
#10
Anything else we might add? /
September 09, 2003, 11:10:56 AM
so, i was just rambling after all... (red-faced with embarrassment)



if you do implement threads, please do it in a simple and transparent way.



meanwhile, i will endeavor to keep correct working definitions of processes and threads separated in my mind (so that they will never again spill out so incorrectly into my posts!  ;-)



thanks for your patience!  --  kazemori
#11
Anything else we might add? /
September 08, 2003, 03:54:23 PM
at the moment i am only thinking about the future (what i may have to do). certainly for limited problem-spaces, i agree that running multiple instances of newLISP (communicating via sockets) is a straight-forward and acceptable solution.



is it possible to limit the "scope" of a thread, so that it is not necessary for all symbols and user-defined functions to be shared? newLISP already implements contexts, in effect creating multiple namespaces (newLISP is a Lisp-n  ;-) -- is it possible to limit a thread's "scope" to its calling context? consider a single instance of newLISP with at least n = 4 active contexts (SYS, MAIN, user-context-parent and user-context-child), wherein the "child" context is the calling context:



(a) perhaps this would limit resource allocation on a per thread basis (overhead). 80kb per thread is an objectively modest requirement; however, it is subjectively large (comparable to an instance of newLISP).



(b) by extension, demonstrating concurrency across many threads would be analogous to the object-oriented paradigm operating over simultaneous instance methods.



(c) if a thread "needs" to encompass the entire superset of namespaces, this is (more or less) the functional equivalent to a new instance of newLISP, in that a separate instance provides (relatively) equivalent functionality.



of course, i may just be rambling now... ;-)



thanks!  --  kazemori
#12
Anything else we might add? / query: threads in newLISP?
September 08, 2003, 10:20:11 AM
hello Lutz!



you have been rather busy! these past days releasing so many updates to newLISP; i have been reluctant to burden you with additional questions.



here is a general interest query: does newLISP support threads? threads are never mentioned in the newLISP documentation, so one could assume the negative.

(and we all know what happens when we assume ;-)



if threads are not supported, would implementation be difficult (like "never-going-to-happen" difficult), and do you have any plans in this direction?



thanks in advance for your time! -- kazemori
#13
newLISP newS /
August 29, 2003, 09:22:06 PM
hello Lutz!



thank you for the 7.10 release. as far as brackets [!] are concerned, they are now accepted in lieu of parentheses by PLT scheme. PLT code uses [] as a means of breaking up the confusion of deeply nested structures. as a visual trick, it actually works out quite well.



brackets also offer the advantage of not shifting (eliminate keyboard remapping -- my trick ;-).



so, hang on to those [!] for now[!]



kazemori
#14
newLISP in the real world /
August 27, 2003, 01:24:38 PM
thank you eddie! ...and thank you lutz!



so much to do...



kazemori
#15
newLISP in the real world /
August 26, 2003, 09:13:21 AM
hi all,



i have downloaded SciTe and will try it out today. i have also downloaded a few other editors to "test drive". if any of these editors are promising (and play nice with newLISP =) -- i will post some information with a new thread.



cgi reminds me too much of my time with perl...no thanks! javascript (in the form of jscript) is built into windows, so i have been using jscript and vbscript to torment my notebook. i have an idea to use a script to initiate newLISP (connect to internet : load newLISP : load one Tk-script : disconnect from internet : hand-off newLISP).



if this is tiny hack successful (and if anyone is interested...) i will make the script available.



kazemori
Pages1 2