My wish list (some proposals for a future newLisp version)

[ale870]

Hello,



I think, since newLisp is not a "normal" lisp, I have some requests to drammatically improve the tools available (in terms of developer flexibility).



Introduce some other native data types, like...



==> DATE / TIME:

In this way I could manage dates as a native type. For example I could make: (+ 12-jan-2009 5) -> date + some days, without converting in strings. It could even manage some "standard" date/time formats, like: 12-jan-2009, 12-jan-09, 12-01-09, etc... Same concept for time.



===> HTTP and EMAIL:

Instead working with http using strings, I could directly manage like a native datatype. This could even get more control over wrong syntax. For example:

http://www.google.it">http://www.google.it    (without apex like string).

Introduce some functions to work with those datatypes. For example:



(get-domain http://www.google.it/index.php">http://www.google.it/index.php) --> http://www.google.it">www.google.it

or...

(get-domain http://www.google.it/index.php">http://www.google.it/index.php 1) --> "it" (first level domain).



Same concept for email, ftp, udp.



===> 2D or 3D or n-D points (vectors):

I could manage points like coordinates:

(+ 12.13 2) ==>14.15   <vector> 11.16



Same thing for 3D or even 4D: 1.2.3  or 1.2.3.4



===> BINARY FORMAT and other native formats like IMAGE, SOUND, etc...



===> "TAG" datatype, useful for HTML and XML:

<a>



Generally speaking, I think that introducting some other native datatypes could give us some improvements:



1) Better check (for errors) from newLisp engine.

2) Faster usage and faster execution (native datatypes are usually managed better than "artificial" ones, since there could be no reason to make conversion. For example, images to work with date and times: one must always convert date to string and back.



For example:

Code Select Expand


(dotimes (x 30)
  (+ 1-jan-2009 x)
)

>> 1-jan-2009
2-jan-2009
3-jan-2009
...


3) Script will be shorter.

4) I really don't like (generally speaking, and not related to newLisp only) always work with strings since programming languages do not manage other datatypes than numbers and strings. I think a scripting language should supply some more powerful datatypes.



My 2 cents opinion.



What do you think about it?

[cormullion]

==> DATE / TIME:

In this way I could manage dates as a native type. For example I could make: (+ 12-jan-2009 5) -> date + some days, without converting in strings. It could even manage some "standard" date/time formats, like: 12-jan-2009, 12-jan-09, 12-01-09, etc... Same concept for time.

Perhaps the idea of object programming and FOOP is designed to provide solutions to these problems. It can sometimes be better if domain-specific functions are provided as separate source modules, allowing the author(s) to provide more rapid development than the base newLISP system, and allowing you the opportunity to customize them to your needs, which you can't do unless Lutz decides to add exactly what you want to the base system... :)



With http://unbalanced-parentheses.nfshost.com/downloads/timeutilities.lsp.txt.html">Time FOOP, for example (not the greatest module ever written, just an exploration of ideas), you do stuff like this:

Code Select Expand

(set 'christmas-day (Time 2008 12 25 0 0 0 300))
(:day-name christmas-day)
;-> "Thursday"
(:shift christmas-day -48 'hours))
(:rfc822 (:shift christmas-day -48 'hours))
;-> "Tue, 23 Dec 2008 00:00 GMT"

You can even (I think) override the "+" operator:

Code Select Expand

(:+ christmas-day -48 'hours))

to get closer to your ideas, but personally I don't like mixing it up like that.



In this particular case, perhaps the speed benefits of native data types are less important, but I can see that that's not always true.

[ale870]

I know what you mean, but I think some basic common types could be implemented in the engine self (with some basic functions to work with it).

Some types like date/time, web (http, udp, tcp, ftp, etc...), email, etc... I think could be implemented as a base, then using your suggestion (FOOP) they could be easily extended and customized.

For example (extreme example, but just to better highlight the "core") imagine have a language using only strings (similar to TCL): now try to use FOOP to implement INTEGERS, FLOATS, etc... It is possible, but you could have a big overload.

[Tim Johnson]

I haven't test corumullion's module yet,

Don't have the <grin>time</grin right now

but it looks as feature-rich as rebol time/date datatypes.

/tim/rebol/core/linux/web

[ale870]

Yes, I was really thinking to rebol and its datatypes... it was one the features that I like on rebol.



See here some details (and hints...):



http://www.rebol.com/r3/docs/datatypes.html">//http://www.rebol.com/r3/docs/datatypes.html

[newBert]

I like Rebol very much but personally I don't like that proliferation of datatypes when we can easily create ours own (in NewLISP as well as in Rebol moreover) if need be.



So we can "personalize" or adapt the type(s) to the actual situation without cluttering the core of the language ... I think many datatypes can be reduced to/composed of simpler few common types (number, string, list).

IMHO ;-)

[ale870]

Yes I know what you say.

In fact I think we could find a way between the solutions "nothing" and "everything".



For example, date and times are so frequently used (and they are one of the biggest problems for a programmer). Same approach for some other datatypes. I agree with you, Rebol has too many datatypes, and someones can be "implemented" via newlisp self.

I think we could discuss only about some other "core" datatypes (this will even help us to make standards).

[Tim Johnson]

I've got such a large code base in rebol, it is hard to leave it behind. All the same,

I believe my next small web project is going to be in newlisp.

I've not made full use of the proliferate number of datatypes in rebol, but rebol has

one feature that I find greatly helpful - and that is the function interface dialect that

enables datatyping of arguments:

example for non-rebolers:

Code Select Expand


foo: func[arg1[string! block!] arg2[integer! decimal!]][
;; code here
]
;; the binary will through errors if arg1 is neither a string or a block or
;; if arg2 is netiher an integer or a decimal

It is some compensation for rebol's vague error reporting.

I don't miss that feature in python because of python's advanced error reporting,

pinpointing errors to file, line number and function.

tim

[newdep]

Ha ..yes Tim I know.. I read some of your messages in the mailinglists..

I stopped last year with rebol after following it for 8 years.. R3 team is pulling my patience a little too much..So Ill give it a try if R3 knows where it stands and is fully functional ;-) Currently Ill rather learn Python 3.2 or Perl 6 then R3.. I still do very much love Rebols architecture..wonderful!

Still I cant drop newlisp for a second.. it keeps tickling my brain ;-)

[Tim Johnson]

.So Ill give it a try if R3 knows where it stands and is fully functional ;-) Currently Ill rather learn Python 3.2 or Perl 6 then R3.. I still do very much love Rebols architecture..wonderful!

As for R3 .... nothing is certain until *after* it happens.

[cormullion]

A stray thought...



So many of the requests to this forum are of the form 'please add feature X to the language'. (I submit quite a few myself...! :) And often, the logical answer is usually in the form of a few lines of source code, a work round, or a source-code module that mostly does the job without requiring changes to the compact, fast, simple, and consistent newLISP engine.



But potentially there's a middle way, of course, adopted by many programs we use daily: the plug-in system. Plug-ins are typically compiled extensions to a base system that provide the necessary performance that an interpreted script cannot. A newLISP plug-in could add new primitives to the language, while remaining entirely optional for those who don't want those features or the increased code size or whatever (think "Flash plug-in for web browsers" !.)



Of course, I have no idea as to whether this would be a realistic engineering challenge! Fitting it into an existing system without disruption would be a major task in itself, and I'd  be clueless as to how you'd write such plug-ins even if they were possible to write. No doubt some sort of C programming would be involved... :(



Edit: I don't see how this really answers the demand for more datatypes, though. Presumably every newLISP primitive would have to be modified to recognize and accept the new datatypes. So println, string, reverse, etc. would have to be modified to be able to accept a new datatype. I can't see it happening... :)

[Tim Johnson]

Patch?

http://linux.about.com/od/commands/l/blcmdl1_patch.htm">http://linux.about.com/od/commands/l/blcmdl1_patch.htm