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

Pages 1 2 3 4
#16
newLISP in the real world / how to wrap functions from a context without prefixing?
June 19, 2013, 05:50:58 PM
This is a mock-up to simplify my question.

I got these scheme:



[*]hin.lsp
Code Select

(context 'hin)

(define (hin-show)
(println "from hin.lsp"))


  • [*]wrappers.lsp
    Code Select

    (load "hin.lsp")

    (define (wrap-one)
    (context hin)
    (hin-show) ; this wont work
    (context MAIN))


  • [*]main.lsp
    Code Select

    (load "wrappers.lsp")

    (wrap-one)
    • [/list]

    File hin.lsp contains 244 symbols (functions and constants) autogenerated. It's a DSL for HTML5.



    File wrappers.lsp contains functions to wrap snippets of reusable code like: header, navbar, sidebar, you-get-the-idea.



    File main.lsp calls functions from wrappers.lsp.



    Now, the context switch shown in function wrap-one wont produce the desired result. I think it's because the double pass newlisp parser does. So on the first pass (hin-show) gets transformed into (MAIN:hin-show).



    The idea of hin.lsp is to be able to wrote code like this:
    Code Select

    (html lang= "en"
    (head
    (title "Some title"))
    (body
    (p class= "shiny" "Lore ipsum...")))


    If I have to prefix every call with "hin:" or even with an alias like "h:" hin's while purpose is defeated, which is to be as close to HTML syntax as possible.



    My question is: what's the best way to wrap functions calls from hin inside a function defined in another context without prefixing hin calls?



    I'm trying to build a macro to parse those calls by my own and prefix when appropriate, it will be used like this:
    Code Select

    (define (wrap-one)
    (wrap-in-context
    (...))) ; calls to hin functions


    But I'm having problems recurring inside the macro. And now I'm thinking all this extra parsing could make the whole idea to work too slow. Anyway, I'm digressing. Back to the point: any ideas about how to avoid prepending all calls with context name?
    #17
    So, what can you actually DO with newLISP? / gocurcon: Google Currency Converter Scrapper
    June 13, 2013, 04:17:53 PM
    Hi all,



    I wanted to share a tiny script which allows me to query google/finance/converter from the CLI.



    It's not much of a scrapper really, but I couldn't come up with a better word to describe it. It does scrap! Really! :P



    Check it here:

    https://github.com/conan-lugmen/newlisp-webscraps">//https://github.com/conan-lugmen/newlisp-webscraps



    I have two questions regarding my code:



    1. Why unify requires uppercase tokens to be able to create symbols with bind? Or maybe my question is this one: Am I correctly using bind/unify? Is that the intended use?



    2. I put a check to consider a get-url not giving back a proper answer. However on some runs I've noticed I get nil results like if my check was passed by. What am I doing wrong there?
    #18
    newLISP newS / Re: newlisp.vim 1.37
    June 02, 2013, 03:03:58 PM
    Thank-you-very-much-indeed! :)
    #19
    newLISP in the real world / Re: Parse very big XML file (Openstreetmap)
    May 28, 2013, 01:55:11 PM
    DISCLAIMER: I haven't worked with big XML files.



    It seems you have to split your XML file but I don't know how that will affect xml-parse.



    However, from the manual:
    Quote
    Using a call back function



    Normally, xml-parse will not return until all parsing has finished. Using the func-callback option, xml-parse will call back after each tag closing with the generated S-expression and a start position and length in the source XML:


    Maybe that could help.
    #20
    Anything else we might add? / Re: Keywords for newLISP in the Clojure style
    May 24, 2013, 03:28:56 PM
    The intellectual exercise was meant to make us think if the language would

    benefit from adding some syntactic sugar. It was never the argument: "This stuff

    cannot be done in newlisp without keywords".



    Maybe I'm shortsighted, but I think about contexts as the last frontier which

    can protect stuff from accidentally being overwritten. An excessive use of

    contexts, in my belief, will eventually pollute namespace.



    On the other hand, one of the cool things of any lisp-like language is that you

    can build one with just seven primitives. So, in lisp-like philosophy, any

    addition should be carefully considered, because any addition is more bloat.



    Perhaps this is just a matter of taste.
    #21
    Anything else we might add? / Re: Keywords for newLISP in the Clojure style
    May 24, 2013, 07:12:16 AM
    Relating the side note: I was wrong when I said I made a self-modifying function, I had just modified a function from another one. Interesting use of pop and push, I'll play a little with it later.



    To the topic at hand:



    We've said keywords could serve three purposes:



    1. as one-time-with-no-previous-registration-required flags



    2. as named parameters in functions



    3. as hash keys



    So, real applications that use keywords?



    My previous posted _choose-method function is a good example: you want to

    decide something inside a function and you just need a flag, no value required.



    One option would be to leave it with a number and document it:


    Code Select

    (define (_choose-method (_method 0)) ...)


    But if one wanted to make the code more self-describing, could create a couple

    of constants:


    Code Select

    (constant 'SAVE_IN_KEYWORDS_CONTEXT 0)
    (constant 'SAVE_IN_CALLING_CONTEXT 1)
    (define (_choose-method (_method SAVE_IN_KEYWORDS_CONTEXT)) ...)


    Using keywords there no need to define the constants and code gets

    self-documented:


    Code Select

    (define (_choose-method (_method .save-in-keywords-context))
    (if (true? .save-in-keywords-context) ...))


    As you can see, for this use case, is a matter of practicallity, just a

    "syntactic convenience" as you explain in the manual for the let form.



    Another example, I have a set of PHP functions like these:


    Code Select

    public function select($query, $index_by = null) {
    public function select_all_by_pk() {
    public function select_all() {
    public function select_all_with_foreign_keys()
    public function select_one($id) {
    public function select_field($id, $field) {
    public function select_by_field($field, $value) {


    If I were to program these in newlisp, I would like to have just one select

    function, and be able to say:


    Code Select

    (select query .index-by-title)
    (select .all-by-primary-key)
    (select .all)
    (select .all-with-foreign-keys)
    (select id)
    (select id .field-title)
    (select field .by-field)


    And another one: when you don't need to mix options, like in the function timer, you could use keywords:
    Code Select

    ; so
    syntax: (timer sym-event-handler | func-event-handler num-seconds [int-option])
    ; could become
    syntax: (timer sym-event-handler | func-event-handler num-seconds [.real-time | .user-time | .profiling-time])

    For the second use case, as named parameters, Lutz shown this:


    Code Select

    (define-macro (foo:foo)
       (local ($len $width $height)
          (bind (args) true)
          (println "len:" $len " width:" $width " height:" $height)
       ))


    (foo ($width 20) ($height 30) ($len 10)) ;=> len:10 width:20 height:30


    With keywords it would be like this:


    Code Select

    (define-macro (foo:foo)
    (println "len: " .len " width: " .width " height: " .height))

    ; and called like this:
    (foo .width 20 .height 30 .len 10) ; -> len: 10 width: 20 height: 30


    And there will not be any global variable, just a property name on a property

    list.



    For the third case, as hash keywords, this is what we currently have:


    Code Select

    (new Tree 'Myhash)
    (Myhash "var" 123) ; create and set variable/value pair
    (Myhash "var") → 123 ; retrieve value


    With keywords:


    Code Select

    (new tree 'MyHash)
    (MyHash .title "The Razors Edge")
    (MyHash .year 1990)
    (MyHash .artist "AC/DC")
    ; still allow any string to be a hash symbol
    (MyHash "rating" .10/10) ; and allow a keyword to be a value
    ; look how self-describing is the .10/10 keyword


    I don't think it's much of an improvement, besides saving three keystrokes. I think is just and extension of the two previous uses: as a flag holding a meaning, and as a symbol holding a value.



    I think the benefit of this kind of type is that it can hold a value: itself, which is just another way of saying "true", or a specific value like in named parameters. And at the same time be self describing.



    In my first example one has to resort to cryptic numbers or set constants if self description is desired.

    In the .10/10 example, I'm saying with just one keyword: "I'm giving a value of 10 to this CD. Scale goes up to 10."



    Note: Maybe I'm blurring the waters with this one. It was a last-minute thought.

    Translation: I haven't thought well the last one.



    As for the implementation details, I got several doubts. My only certainty is that our keywords should not live all mixed up in a special context called Keywords, but be part of the context they're defined.
    #22
    Anything else we might add? / Re: Keywords for newLISP in the Clojure style
    May 22, 2013, 08:36:59 PM
    First, so you know we're on the same page: I'm for the inclusion of keywords, like the ones I talked above (which I think are the same you're asking for), in newLisp.



    However, I'm not quite comfortable with using colon as keyword designator since it already has another uses in newLisp, and even if it can be implemented safely in the interpreter, still will add a burden to the reading programmer: because he/she'll have to interpret which meaning has the colon when reading code. So I root for the use of dot instead. It's an unused character which can be reached with one single keystroke.



    I think if we gonna make a case for the inclusion, then we should first try hard to show it cannot be done or cannot be done in a practical way. And second, we should show some cool practical uses for it (in fantasy code, of course, because the thing doesn't exists).



    Now, regarding my function, I agree the register step is not to cool:


    Code Select

    ; this is awkward
    (some-function (. 'with-mustard))
    ; this is more straightforward
    (some-function .with-mustard)


    Regarding MAIN pollution, I think that's because of the double pass newlisp does when reading the source, cause anything you type in a symbol place will be added to MAIN:


    Code Select

    $ newlisp
    newLISP v.10.5.0 64-bit on Linux IPv4/6 UTF-8, options: newlisp -h

    > z
    nil
    > (symbols)
    (...
    ... z ...)
    >


    I fixed that problem with this:


    Code Select

    (define (_in-keywords _symbol (_value nil))
        (constant (sym (term _symbol))
            (if (true? _value)
                (eval _value)
                ; else
                (sym (term _symbol))))
        ; in any case delete symbol created inside MAIN
        (unless (true? (eval _symbol))
            (delete _symbol)))


    Note: is the same dot functor from my previous post, but I copy pasted from the module attached in this post, where I changed several names for convenience and "safety" (by convention, not real safety).



    The deletion is safe, if you got the symbol explicitly defined, then it will not be deleted nor overwritten.



    I would like to see your attempts with the reader event handler if you got them handy.



    I'm attaching a module Keywords, should have defined a default default functor, but I'm burned out right now. Check it out.



    Finally: Lutz has said several times something like: "Don't try to program in newlisp as if it's language <insert-language>". This is not an attempt to make newlisp be like any other language, is stealing from other language what I believe is a nice feature.



    ... (edit)... After three attempts I couldn't upload the file, board says: "The extension is not allowed". So I'll add it inline:


    Code Select

    #!/usr/bin/env newlisp
    ;; Creation Date: Tue, 21 May 2013 23:01:38 -0300
    ;; @author Fernando Canizo (aka conan) - http://conan.muriandre.com/
    ;; @module Keywords
    ;; @description Keywords (almost) a-la Common Lisp
    ;; @version 2013.05.22
    ;;
    ;; This module provides a keyword facility for symbols.
    ;; Use default functor to create keywords like the ones in Common Lisp, which are
    ;; symbols evaluating to themselves (unless a value is given) living in the
    ;; Keywords context.
    ;; Use dash functor to create keywords living on the context from where the
    ;; function is called.


    ;; @notes
    ;; Couldn't make default functor self modifying, had to use _choose-method instead
    ;; When the chooser was the default functor, newlisp core dumped

    (context 'Keywords)


    ;; @syntax
    ;; @param
    ;; @return
    ;; @example

    (define (_choose-method (_method 0))
    (if (= 0 _method) ; store keywords in this context by default
    (setq Keywords:Keywords (append (lambda) (list (first _in-keywords)) (rest _in-keywords)))
    ; else
    (setq Keywords:Keywords (append (lambda) (list (first _in-calling-context)) (rest _in-calling-context)))))


    ;; @syntax
    ;; @param
    ;; @return
    ;; @example

    (define (_in-keywords _symbol (_value nil))
    (constant (sym (term _symbol))
    (if (true? _value)
    (eval _value)
    ; else
    (sym (term _symbol))))
    ; in any case delete symbol created inside MAIN
    (unless (true? (eval _symbol))
    (delete _symbol)))


    ;; @syntax
    ;; @param
    ;; @return
    ;; @example

    (define (_in-calling-context _symbol (_value nil))
    (context (prefix _symbol))
    (constant (sym _symbol)
    (if (true? _value)
    (eval _value)
    ; else
    (sym _symbol))))


    (context MAIN)
    ; set a shortcut
    (constant '. Keywords)


    On a side note: I did some toy-tests to make the default functor be a self modifying function. They worked. But when I tried to do the same with this one, I got a segmentation fault. I'm puzzled.
    #23
    Anything else we might add? / Re: Keywords for newLISP in the Clojure style
    May 21, 2013, 06:29:58 PM
    Indeed I was writing my post around the same time Lutz did, so I didn't see his post. That foo macro looks like what I think I saw.



    Anyway, rickyboy, I don't know about keywords in Clojure, but I think it stole them from CL, I think Ruby did the same. Well it doesn't matter. I thought you were referring to CL keywords and this is their definition from http://www.lispworks.com/documentation/HyperSpec/Body/t_kwd.htm">//http://www.lispworks.com/documentation/HyperSpec/Body/t_kwd.htm:


    Quote
    Type KEYWORD

    Description:

    The type keyword includes all symbols interned the KEYWORD package.

    Interning a symbol in the KEYWORD package has three automatic effects:

    1. It causes the symbol to become bound to itself.

    2. It causes the symbol to become an external symbol of the KEYWORD package.

    3. It causes the symbol to become a constant variable.


    I also found this one which doesn't add to much, but puts keyword in context with symbols: http://www.mad-computer-scientist.com/blog/2010/12/04/symbols-vs-keywords-in-common-lisp/">//http://www.mad-computer-scientist.com/blog/2010/12/04/symbols-vs-keywords-in-common-lisp/



    I'm not sure it's necessary to make an addition to the language, Lutz already shown that's possible to make named parameters, which solves point five.



    Maybe we can just fiddle a little bit with code and see what comes up ;)



    So from CL we got: it's a constant, bound to itself (the same symbol) and lives in a special package (we can think about it as a special context, or maybe just a plain context).



    I got this:


    Code Select

    ; think of the dot context as the CL special Keyword package
    (define (.:. a-symbol (a-value nil))
       (constant (sym (term a-symbol))
          (if (true? a-value)
             (eval a-value)
             ; else
             (sym (term a-symbol)))))


    Code Select

    > (. 'y)
    .:y
    > .:y
    .:y
    > (. 'y "babula")
    "babula"
    > .:y
    "babula"


    The use I like about this kind of "type" is when you wanna pass an option to a function that the only thing it needs to say is "true", in order to do-some-stuff. When you only need to say "true" but you wanna do it in a literate way, they become handy: it's only existence indicates a true value, so we don't need to store a value.



    However they can be used to hold a value in CL and, if we want to emulate that, then by making all keywords live in the same "special" context we would get into trouble soon.



    The dot functor solves point one because keywords defined with it evaluates by default to itself. Also point two, because they are in the dot context, so no clutter. Also point three, you wrote literate code that way. Point four was addressed by Lutz. Dot functor address point five, just with an extra character. And, finally, I don't know about point six.



    In fact I think I need to work more on that dot functor, since I don't like it for holding values, I prefer values stay local, in context.
    #24
    Anything else we might add? / Re: Keywords for newLISP in the Clojure style
    May 21, 2013, 11:08:41 AM
    Title could also be "Keywords for newLISP in the Common Lisp style".



    I agree those kind of keywords are useful.



    Also, is it possible I've seen some macro-stuff here in the forum to emulate them?
    #25
    Whither newLISP? / Re: magic numbers
    May 18, 2013, 12:05:45 PM
    Quote from: "Lutz"prefix is a built-in function and should not be redefined without an appropriate reason.


    Ooops! I just wanted an innocent constant, not trying to redefine anything.



    Didn't want to use uppercase characters to avoid a possible collision with the constants that will be defined. I'll change it.
    #26
    Whither newLISP? / Re: magic numbers
    May 18, 2013, 07:09:59 AM
    Quote from: "bairui"
    For a while now I have been unconsciously squirming in my seat when reading over code like this. This morning I became aware of that discomfort and cried in alarm: magic numbers!



    To the trained webber this might read transparently lucid; succinct even. But to the novice seeing this for the first time or the junior revisiting six month (week? day?!) old code, these opaque little numbers muddy the cognitive stream, making it nearly impossible to reason about the code until the manual has been consulted.


    I agree. In particular I think the benefit of having verbose-constants for each code is not on the writing side, but on the reading side. Because when you're writing code you'll probably end up checking the manual anyway. But when you read code, you want to understand what's happening right away without the need to check a manual. So better to have verbose constants.


    Quote from: "Lutz"
    In principle, I agree, but defining symbols for all 'Magic number constants' used in newLISP would grow the small minimalistic newLISP executable and memory footprint.


    I agree with that too. And also I like cormullion's approach of building the constants programmatically.



    I thought this would be a nice and easy project for a person like me, coming again to newLISP after nearly a year, and having forgotten almost everything about the language.



    So I created this project: https://github.com/conan-lugmen/newlisp-constants">//https://github.com/conan-lugmen/newlisp-constants



    It's based on cormullion idea of building constants programmatically, though I used predefined sets of values (taken from the manual) to build NewlispErrorCodes and NetErrorCodes.



    I think it would be a nice addition to newLISP to slightly modify last-error and net-error to return the full list of possible codes so the modules could build all constants programatically.



    Also if sys-error codes gets built into newlisp at compilation time, then it can be modified too that way.



    I think it wouldn't be much overhead to add an if to test for the given parameter and if it's, say... a string saying "show all" or maybe a negative integer, then return the full list of codes for that function.



    What do you say Lutz?



    Anyway, the Constants module can be used to build any kind of constants, though I agree with bairui that it would be nice to have some set of predefined/standard ones.



    I made it verbose, but users can always do a:


    Code Select
    (constant 'C Constants)

    Anyway, I had fun making this, whether useful or not, I would like to request for comments on ways to improve code since I'm relearning everything.



    In particular, I'm interested in knowing why I couldn't use:
    Code Select
    (constant 'prefix "XXX")

    I got "ERR: symbol not in current context in function constant : prefix" when I use it like above.
    #27
    Anything else we might add? / Re: Tail Recusion
    May 14, 2013, 05:20:17 AM
    Sorry to bring back to life such an old post. But I left aside newlisp for a while and now I'm catching up. And this got me puzzled:



    I tested the crashing function with -s 47000 and I get a stack overflow:


    Code Select

    46998

    ERR: call or result stack overflow : +
    called from user defined function simple-crash


    (simple-crash has the same definition given by rapega)



    However when I call the same function with -s 48000 I get a segmentation fault:


    Code Select

    47617
    Segmentation fault (core dumped)


    I tried to examine the process by stopping it around the number it will crash, to look for clues to what's happening, so I wrote this one:


    Code Select

    (define (crash x stop)
    (println x)
    (if (>= x stop)
    (begin
    (println "Press ENTER to continue...")
    (read-char)))

    (crash (+ 1 x) stop))


    But couldn't find anything relevant. Memory seems fine, I recover around 100 Kb after the crash. And I didn't see anything strange going on.



    So my question is why I get a segmentation fault with a bigger stack? Shouldn't I get another stack overflow just with a bigger number?



    BTW I'm using newLISP v.10.4.5
    #28
    Anything else we might add? / Re: Blog entry: S-Expressions: The Fat-Free Alternative to J
    July 19, 2012, 09:43:58 AM
    Erm...



    Parse error: syntax error, unexpected ';' in /var/www/virtual/shinkirou.org/htdocs/blog/wp-content/themes/elegant-grunge/functions.php on line 3
    #29
    Dragonfly / [Bug] ERR: list expected: (parse - query QUERY_STRING)
    January 29, 2012, 05:00:13 AM
    I thought dragonfly was unmaintained, but since I've saw some recent post about it in here I decided to give it a try today. So I downloaded it, unzipped it into my ~/public_html, cd-ed into ~/p.../example-site, and run ./newlispServer, and I've got this error:


    Code Select

    ERR: list expected: (parse - query QUERY_STRING)
    called from user defined
    function load - once
    called from user defined
    function load - files - in -dir


    I tried tracing the bug in the definition of load-once in lib/utils.lsp by putting a (throw-error "mark") in different places (to see when was exploding), but it always explode in my throw.
    #30
    newLISP newS / Re: Updated links for modules page
    January 26, 2012, 05:04:49 AM
    Sorry, I'm used to hover over navigation bars and see drop down menus.



    I just noticed on this site you have to click the links for them to drop. It's a cool feature they stay on when you click them, so one can peruse at will without having to hold the mouse over the menu. However I think it's an usability issue not having hovering-drop-down.



    You should provide both ways: hover: transient drop down as 90% of the web, and click: maintain show status until new click, which is the current way of working I experience.
    Pages 1 2 3 4