Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Boleslav Březovský
    @rebolek
    However, you can do this:
    code: [reduce]
    parse data [to quote lot: change quote lot: code]
    code is evaluated in this case and reduce is inserted
    Dmitry Bubnenkov
    @bubnenkoff

    Do not understand about idea about code. I want to change lot: to word object to make data look:

    data: [
        id: 123
        date: "2020" lots: [object [ lotNumber: 1  price: 777 ] ]
        ]

    P.S. omit the previous example with lots. I will integrate it later

    Boleslav Březovský
    @rebolek
    code: [object]
    parse data [to block! into [change quote lot: code]]
    Dmitry Bubnenkov
    @bubnenkoff
    M... it's look like I begin understand logic! One moment!
    Dmitry Bubnenkov
    @bubnenkoff

    Yes I understand your idea, but why are you using to block! into?

    Also if use some it's change only first lot::

    data: [
        id: 123
        date: "2020" lots: [
            lot: [ lotNumber: 1  price: 777 ] 
            lot: [ lotNumber: 2  price: 888 ] 
            ]
        ]
    
    code: [object]
    parse data [ some [
                        to block! into [change quote lot: code]
                    ]
                ]    
    
    probe data
    Dmitry Bubnenkov
    @bubnenkoff

    I have found solution. Not sure that it's good, but at last it readable:

    data: [
        id: 123
        date: "2020" lots: [
            lot: [ lotNumber: 1  price: 777 ] 
            lot: [ lotNumber: 2  price: 888 ] 
            ]
        ]
    
    parse mold data [result: some [
                            to "lot:"  change "lot:" "object"
                          ]
                    ]
    probe to-block result

    result:

    [[
        id: 123 
        date: "2020" lots: [
            object [lotNumber: 1 price: 777] 
            object [lotNumber: 2 price: 888]
        ]
    ]]
    Dmitry Bubnenkov
    @bubnenkoff
    The issue with appearing addition [ :(
    Boleslav Březovský
    @rebolek
    @bubnenkoff why don't you use the solution I shown you?
    >> code: [object]
    == [object]
    >> parse data [to block! into [some [change quote lot: code | skip]]]
    == true
    >> data
    == [
        id: 123 date: "2020" lots: [object [lotNumber: 1 price: 777] object [lotNumber: 2 price: 888]]
    ]
    Dmitry Bubnenkov
    @bubnenkoff
    oh! I missed skip thanks!
    Boleslav Březovský
    @rebolek
    You're welcome. The example hadn't skip because there was just one lot:.
    Dmitry Bubnenkov
    @bubnenkoff
    @rebolek does this code have any nesting limitation? I tried to hange with it nested block (the next task is change object: to object) and it do not work:
    data: [
        id: 123
        INN: "123213142" 
        lots: [lot: [
            lotNumber: 1 
            price: 777 
            objects: [object: [
                name: "Apples"
            ] object: [
                name: "Bananas"
            ]
            ]
            ]
        ]
    
    ]
    
    code: [object]
    parse data [ to block! into [ some [change quote object: code | skip] ] ]    
    probe data
    Boleslav Březovský
    @rebolek
    @bubnenkoff as you can see, it looks for a block (to block!) and then jumps into that block (into ...). It doesn't look for other nested block, but you can change the rule so it would be recursive.
    Dmitry Bubnenkov
    @bubnenkoff
    I tried to wrap it in yet another some
    Boleslav Březovský
    @rebolek
    How would that help?
    Dmitry Bubnenkov
    @bubnenkoff
    no way :(
    Boleslav Březovský
    @rebolek
    Try something like this:
    parse data rule: [some [change quote object: code | ahead block! into rule | skip]]
    Dmitry Bubnenkov
    @bubnenkoff
    wow! thanks! I will try it now
    Boleslav Březovský
    @rebolek
    You need recursive rule, if you want to deal with nested blocks, some will just make the rule match one or more times.
    GiuseppeChillemi
    @GiuseppeChillemi
    Is it possible to SET a matched element to a word in a context? SET does not seem to work on paths. I need to write to OBJ/WORD when parsing. Even a SET in OBJ WORD would be welcome.
    X.A.N.O.Z.O.I.D.
    @XANOZOID
    Are you looking for set in obj 'a "val" ?
    Oh hmm.

    Even a SET in OBJ WORD would be welcome.

    Can you define a quick example of where you're running into the problem?

    GiuseppeChillemi
    @GiuseppeChillemi
    Yes but inside parse block rule.
    X.A.N.O.Z.O.I.D.
    @XANOZOID
    if you want to fudge it a little I imagine you could set it up where you create a structure that looks like do [ obj/word: your-val ]
    GiuseppeChillemi
    @GiuseppeChillemi
    I want to set to context words the values I match with parse.
    Vladimir Vasilyev
    @9214
    >> foo: object [bar: 'qux] ()
    >> parse [baz][set match word! (set/any 'foo/bar :match)]
    == true
    >> foo/bar
    == baz
    GiuseppeChillemi
    @GiuseppeChillemi
    Thanks Vladimir, I am already using this expressive form: parse [x] [set value word! (dd/value: value)] but I was asking if we can do it directly in PARSE SET without using a global word.
    Vladimir Vasilyev
    @9214
    >> foo: object [bar: 'qux] ()
    >> parse [baz][set match word! (set/any 'foo/bar :match unset 'match)]
    == true
    >> foo/bar
    == baz
    >> value? 'match
    == false
    >> parse [baz] bind [set bar word! (set/any 'foo/bar :bar)] foo: object [bar: 'qux]
    == true
    >> foo/bar
    == baz
    >> value? 'bar
    == false
    GiuseppeChillemi
    @GiuseppeChillemi

    (set/any 'foo/bar :match unset 'match)

    This should delete any previous 'match content, shouldn't it?

    Vladimir Vasilyev
    @9214
    Implementing support for paths is a bit expensive, this is the main reason why they are not handled by Parse yet (see here for details).
    GiuseppeChillemi
    @GiuseppeChillemi
    Thanks, this is the reason why we can't use paths in VID, isn't it? No support on parse = no support in VID dialect, just direct words.
    Vladimir Vasilyev
    @9214
    That's totally unrelated. You can parse paths in input (such as VID block), you cannot use them in rules.
    GiuseppeChillemi
    @GiuseppeChillemi
    Ok
    Vladimir Vasilyev
    @9214

    This should delete any previous 'match content, shouldn't it?

    In this scenario, yes. You can easily check it yourself in a REPL though.

    GiuseppeChillemi
    @GiuseppeChillemi
    @9214 Just a last question on your note: if parse paths in rules would be implemented, would this slow down the whole parse or just when using paths in rules?
    Gregg Irwin
    @greggirwin
    General overhead would take a slight hit, as you have another datatype to check for, but the main hit would be when you use them. That's something we can tell users, so they know that using them in heavy processing may have a noticeable impact. It would be a nice feature to have IMO.
    GiuseppeChillemi
    @GiuseppeChillemi
    @greggirwin Thanks for your answer. I am just asking, I don't want to make any pressure. I Iike the idea of having paths either here and on VID styles setup values but actually Red has more important priorities.
    GiuseppeChillemi
    @GiuseppeChillemi
    Now that I am starting to handle parse In the correct way, I want to say that making dialects is really fun!!! How crazy genius has been Carl to invent parse based DSLs?
    I have made a small SET with custom containers in 15 minutes. Redbol make me say "that's the joy of coding"
    Gregg Irwin
    @greggirwin
    :+1:
    GiuseppeChillemi
    @GiuseppeChillemi
    I am loving parse. I am thinking about a lot of use cases: as a grammar oriented case, as a record extractor, as for loop, as special switch, as for-case loop, as foreach. It's incredible how flexible it is!
    Gregg Irwin
    @greggirwin
    It's the jewel in the crown.
    Oldes Huhuman
    @Oldes
    Why is parse so slow when I use it like this?
    data: read/binary http://avatars-04.gitter.im/gh/uv/4/oldes
    dt [loop 10000 [find/match data #{89504E47}]]
    ;== 0:00:00.0039912
    dt [loop 10000 [parse data [#{89504E47} to end]]]
    ;== 0:00:13.6435
    Vladimir Vasilyev
    @9214
    to.
    Oldes Huhuman
    @Oldes
    I believe it's a bug, because the speed of these 2 should be similar.. like in Rebol.
    Gabriele Santilli
    @giesse
    startup time for parse is likely to always be bigger than find.
    Gabriele Santilli
    @giesse
    but I agree that to end shouldn't be that slow... :)
    >> profile/show [[find/match data #{89504E47}] [parse data [#{89504E47} (found?: true)]] [parse data [#{89504E47} to end]]]
    Time                 | Memory      | Code
    1.0x (331ns)         | 512         | [find/match data #{89504E47}]
    2.59x (858ns)        | 168         | [parse data [#{89504E47} (found?: true)]]
    5201.75x (2ms)       | 168         | [parse data [#{89504E47} to end]]
    Petr Krenzelok
    @pekr
    I can agree too. We know that Red is supposed to be slower in certain operations, as R/S is not at C level yet, but the to endoperation looks suspicious :-)
    Vladimir Vasilyev
    @9214
    Rebol2 likely does a peephole optimization for this specific case by checking for end presence.