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 - Dmi

Pages1 2 3 ... 28
#1
newLISP newS /
November 16, 2008, 01:29:11 PM
Quote from: "Kazimir Majorinc"I think we have two issues here. One is denoting unification variables with ~. I agree that it is better than uppercase. Still, it is encoding of information in symbol names. Imagine you have expressions F and G...

[skopped]

Don't you see that it is encoding information in symbol name?

Yes, it is encoding. Anyway there is three cases there:

1. To encode information in symbol names with capitalizing and providing a binding list (current engine).

pros: it is current

cons:

  - unify is not so useful for fast scripting (which is still the horse of newlisp in common),

  - capitalized names are frequent in regular practice, so there will be some problems to map unify bindings to newlisp symbols. (of course we can always use names like UnSymbolName to avoid interference, what means introducing prefix again ;)

2. To encode information in symblol names with rare used prefix (my proposal).

pros: we can map bindings directly to newlisp symbol values.

cons: we lost some virtual language purity (but note, that current unify implementation alog with "bind" suggests exactly this way).

3. To use only binding list for both setting initial binding and enumerating symbols which must be treated as variables. Someting like:
Code Select
(unify '(A B C) '(B C A) '((A 1) (B unbound)))
so there C will be treated as constant.

pros: This is the most pure way.

cons: It is much for academic cases.



My proposal is based on my interest to newlisp: fast coding of complex practical systems.



And, in common analisis about the case I gree with you, Kazimir :)
#2
newLISP newS /
November 16, 2008, 03:40:52 AM
Quote from: "Kazimir Majorinc"
...Because one who uses such unify should encode information (~) in variable name. It is not good. Variable names should be just variable names. Imagine language such that programs look like:

Not so exactly because such (~) variables will not have any special meaning in newlisp code - just variables, like any others, and such prefix will have no special meaning for them in newlisp.



But inside unify forms there is no newlisp rules - there are unification rules, which require that variables must differ from constants and should maintain binding status. Currently for this capitalizing is used.

I only point an attention that prefixing is more useful here if we want unify to be interoperable with newlisp core engine - because ~-prefixing is more rarely used than capitalizing in regular newlisp code.



I suggest such result:

If U want to code without unify, U simply code without unify, even using ~prefixed symbols.

If U want to use unify forms, then using of ~prefixed symbols is the simplest way to:

- get results from unify directly into the code

- issue subsequent unify with implicit maintaining of binding status.
#3
newLISP newS /
November 15, 2008, 12:13:42 PM
I don't see how usage of ~something symbols may break newlisp syntax.



I already can do (newlisp shell example)
Code Select
(set '~something 1)
~something
1

The idea is that actually no syntax breaking will occurs: We already can legally use ~-prefixed symbols as regular symbols in newlisp (also $-prefixed, %-prefixed etc.).

But inside unify exactly thoose ~-prefixed symbols will be subject of binding, which is immediately affected outside unify (without bind function).

So newlisp engine in proposed case should maintain binding status for ~-prefixed symbols for usage inside unify function.



There is already conformism about prefixing in unify - binding variables a capitalized. Capitalising is common for Prolog and Erlang, because it is their syntax. But not for newlisp where capitalizing is not affected language symbols behavior.
#4
newLISP newS /
November 15, 2008, 02:20:18 AM
Yes, they are equivalents... but only if we haven't already binded symbols.



If so, in Erlang this will be:
Code Select
{IP, _}={"127.0.0.1", something},
....
{IP, Port, {Type, Request}} = {"127.0.0.1", 8658, {"GET", "something"}}

this is the actual form. Whether the unification fails, the exeception is thrown (excluding the "case" variants etc.)



and the actual form in nwelisp:
Code Select
(set 'meaningless (unify '(IP Something) '("127.0.0.1" "something")))
....
(let (meaningless2 (unify
  '(IP Port (Type Request))
  '("127.0.0.1" 8658 ("GET" "something"))
  meaningless)))
  (if meaningless2 (bind meaningless2)
      (do-some-if-unify-fails)))


The one of points of my proposal is introducing of new namespace for binded values, which lives together by newlisp laws and by unify laws.



And the other points are the "case" and "define" forms which can be emulated with macros, but this isn't so useful.
#5
newLISP newS /
November 14, 2008, 04:24:58 PM
Thinking about unify example for newLISP, I found, that Erlang style unification can perfectly fit newLISP.

The very cool usage proposal for unification in Erlang is extracting parameters from complex list/touple structures.

I.e.:
Code Select
{IP, Port, {Type, Request}} = {"127.0.0.1", 8658, {"GET", "something"}}
will result in bindings:

IP = "127.0.0.1", Port = 8658 and Type= "GET" and Request = "something".

In the other hand, if pattern structure and bound variables/constants will not match, the unification will fail.



But, let's return to newLISP...



newLISP have a good proposal for wide usage of similar unification because it's major and the best data structure is a list, which can be structured.

Say,
Code Select
("127.0.0.1", 8658, ("GET", "something"))

Unfortunately, current unify syntax is not so laconic as Erlang.

In short, I propose the new unify engine where

- unification variables (that's are bounded or may be binded) will be represented as regular newLISP symbols, prefixed with "~" (or another one).

The "bound" state of this variables must be handled implicitly. And I suspect, that this variables possible should be local to current function in stack.

- all other newLISP symbols, used in unify will be treated as constant, given by value.

- the short name (say "~") for "unify" ;-)

- the form of define (say define~) which defines the function like an Erlang/Prolog predicate.

- the form of case (say case~) which have variants based on unification patterns.

Consider this virtual example:
Code Select
(set 'ip "127.0.0.1")
(set 'rq '('test-assign 1234))
(~ (~ip ~port ~request) (ip 8658 ('SET rq)))
(print ~ip ":" ~port)
# will print 127.0.0.1:8658
(if (member ~ip allowed-ip-list)
  (execute-command ~request))
....
(set 'something '("def" 25 4))
(case~ something
  (("abc" ~second) (do-something ~second))
  (("def" ~second ~third) (+ ~second ~third))
# will return 29
....

(define~ (execute-command ('GET ~what))
  (lookup ~what global-prop-list))

# this one will be called for our example
(define~ (execute-command ('SET (~what ~to-what)))
  (push (list ~what ~to-what) global-prop-list))

(define~ (execute-command ('CHECK (~what ~to-what)))
  (u~ (~what ~to-what) (assoc ~what global-prop-list)))
# here identical to
# (= (list ~what ~to-what) (assoc ~what global-prop-list))
# but in common may be much powerful

I mean' that when we call execute-command, newLISP will pass through all versions of it, trying to unify arguments, and execute the first where unification succeeded.



To Lutz: Probably, this innovation may introduce the new interesting technics into a language, and also will not break other features and preserve backward compatibility.
#6
newLISP newS /
November 11, 2008, 03:08:47 PM
Lutz: Wow! This would be nice!

newdep: No! Please! ;-)
#7
newLISP newS / Shared memory proposal
November 11, 2008, 04:31:58 AM
Hi, Lutz!



Last time I study Erlang and I found a useful thing that, imho, can significant simplify the newlisp asynchronous tasks when we need to fork and to use semaphores/shared memory.



I think it would be cool to have some engine over shared memory when one process can issue
Code Select
(send-message Pid message)
to send a regular newlisp value to the shared-memory queue of forked process Pid.

and other process can issue
Code Select
(receive-message) -> (Sender_Pid Message)
to receive next message from it's queue.



Probably, some blocking/non-blocking options etc. may be applicable here



The Erlang's version of this is much more powerful, but highly related to Erlang features.

But I think, that even this level of messaging will be more user-friendly and human-error free than concurent access to shared memory.
#8
newLISP newS /
November 11, 2008, 03:56:27 AM
In simple words, unification is a method to match structured data to a template so

- binded symbols and constants will be compared to corresponding data structure elements

- unbinded symbols will be binded (assigned to) with corresponding data structure elements

If mathcing has no conflicts, them unification is successful.



The power of unification is that there can be several templates which are applied sequentally until success.



Some examples from Erlang world:

(note that in Erlang "Capitalized" words are variables and "regular" words are just constant names which means themselves)



Function arguments unification:
Code Select
handle(create, What, Where) -> create_object(What, Where, other params);
handle(extract,sysdate, dual) -> now();
handle(extract,"hello", dual) -> string("Welcome dear " User);  
handle(extract, What,Where) -> find_object(Where, What).


next we can call:
Code Select

X=sysdate,
Y=dual,
hanle(extract, X, Y)


This will result in the call to function now().



Real example:
Code Select
start(mysql) ->
    % make db connection
    {};
start(mnesia) ->
    % make db connection
    {};
start(odbc) ->
    % make db connection
    {};


Example with case statement:
Code Select
case Var of
  {"create", What, Where} -> create_object(What, Where, other params);
  {"extract","sysdate", "dual"} -> now();
  {"extract","hello", "dual"} -> string("Welcome dear " User);  
  {"extract", What,Where} -> find_object(Where, What)
end.

Var can be touple {"extract", some-object, some-table} etc.



While this technics are available the code can became very elegant sometimes...
#9
Anything else we might add? /
October 27, 2008, 01:24:43 PM
QuoteНо, боюсencedь, человек, для которого этот язык будет первым, к неряшливому стилю привыкнет на всю жизнь.



But someone who starts using NewLisp as his first language //meaning, first Lisp variation -- translator// will get used to an untidy style for life

Hmm... just my 5 cents here: Personally me, programming newlisp, have the minimum possible errors quantity. Comparing C, Pascal, perl, awk, tcl, erlang....

My 100 - 300 lines newlisp programs are always runs just as being written, and, after that, I have smallest error corrections within them in my programming practice.

Yes, newlisp can cause bad style.

BUT newlisp can cause a good style also - languages like C, perl, erlang haven't this feature by design. imho.

;-)
#10
newLISP newS /
July 01, 2008, 12:22:31 AM
Hi, Lutz!

Thanks for reply!



Just checked on Intel Celeron with the same Linux version - all seems to be ok.

Initial test was on Amd64 Thurion with newlisp compiled in 32-bit mode from the same package.



I can't to find any other differences yet... Can I do some system checks to catch?



Thanks for time-shift trik.
#11
newLISP newS / parse-date %Y
June 30, 2008, 03:57:33 PM
Code Select
> (date (parse-date "2008" "%Y") 0 )
"Sun Dec 31 08:05:04 8676"

Year is 8676 instead of 2008 expected.



newlisp 9.3.12, Debian Linux
#12
newLISP newS /
May 23, 2008, 01:51:21 PM
Repository for Debian/Ubuntu at http://en.feautec.pp.ru">http://en.feautec.pp.ru is updated.

Fixed library path in gmp.lsp (thanks Ted Walther)
#13
newLISP and the O.S. /
May 02, 2008, 02:22:22 PM
Ho! It's new for me! But you're right:
Code Select
void main(void){printf("%in",sizeof(int));}
prints 4, not 8 as I've expected



But linux distro is 64-bit, so, I suspect, mysql is compiled in 64bit mode.
#14
newLISP and the O.S. /
May 02, 2008, 12:05:47 PM
Hi, Lutz!



Hmm... my one is compiled from makefile_debian (as standard package).

The compile options are:
Code Select
gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -g -DREADLINE -DLINUX  -O2 newlisp.c

Compiled and runs on dual core amd64 thurion in 64bit mode.

No problems in newlisp found.



mysql version is 5.0.51a-3

I haven't test it with 2G+ databases : Do you looking for test?



For offsets I have compiled ad ran sql.c.

Changing offset multiplier from 4 to 8 was intuitive bug fix lookup ;-)
#15
newLISP and the O.S. /
May 02, 2008, 07:33:15 AM
Dmytry Krasilnikov, working with me, found another bug in mysql5.lsp:


Code Select
(define (fetch-all)
  (dotimes (x (num-rows)) (push (fetch-row) all))
  (reverse all))

symbol 'all is global and here was no reset for it.


Code Select
(define (fetch-all , all)
should correct this.
Pages1 2 3 ... 28