Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 31 to 40 of 41

Thread: Map literals in ASH (potential feature)

  1. #31
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    D.C. suburbs of Virginia, USA
    Posts
    3,638

    Default

    I applied the patch from the first post. zarqon's example just netted him 10 meat and some bat crap, but my DCQuest which calls datelib had "Internal error (datelib.ash, line 28)" which suggests something changed for the worse. Not ready for prime time since my time to diagnose is momentarily limited.
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post
    There are 69 players more powerful than you.
    Originally Posted by Statistics Leaderboards

  2. #32
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    Not sure, haven't tried out datelib with this patch. I'll look into it (since that is evidently my script :P).

    edit: ooh, that was quick. As I discovered earlier in the thread (which led to the massive derailing), any variables with the name of an existing type will cause the interpreter to throw an error (because of the change to control flow -- said patch causes Mafia to try to parse map literals before variable references, and I wasn't sure how to put tokens back onto the stack).

    Said patch still needs cleanup, naturally (for instance, standalone expressions like "ash int[int] {1: 2};" will throw a different error).

    double edit: fixed both issues; new patch attached here. Will also add to first post.
    Attached Files
    Last edited by heeheehee; 08-14-2012 at 01:52 AM. Reason: patch!

  3. #33
    Senior Member
    Join Date
    Mar 2012
    Posts
    246

    Default

    Any chance of this getting merged?

  4. #34
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    Bumpity bump bump. Funny story, actually. Someone pinged me about map literals in ASH a few weeks ago, citing this thread (which I'd totally forgotten about). I checked out this patch, and other than trailing whitespace, it applied and compiled without any complaints. Good job, self from 2012!

    I never did fix the issue with array literals, but I'm still not sure that anyone might care about it (as I mentioned, plural typed constants are superior if you can use them). I'm thinking I'll commit this once I take a look at what I did and see if there's anything I can improve, unless there are any reservations.

  5. #35
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    r16866 commits this; docs can be found in the commit notes. One outstanding issue I noticed:

    Code:
    int [int]
    {
        4 : 3,
        5 : 6
    };
    throws a script parsing error, while
    Code:
    (int [int]
    {
        4 : 3,
        5 : 6
    });
    does not. I personally think this is a non-issue, since there's no reason to use a map literal without using its value anywhere.

  6. #36
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    10,530

    Default

    We can do this:

    Code:
    item [int,int] imap = item[int, int] {4: item[int] {4: $item[eyepatch]} };
    
    record rec1 { int a; string b; };
    
    rec1 [int,int] rmap = rec1[int, int] {4: rec1[int] {4: new rec1( 10, "abc" ) }, 10: rec1[int] {40: new rec1( 100, "xyz" ) } };
    Can we do this:

    Code:
    item [int,int] imap = {4: item[int] {4: $item[eyepatch]} };
    
    record rec1 { int a; string b; };
    
    rec1 [int,int] rmap = {4: rec1[int] {4: new rec1( 10, "abc" ) }, 10: rec1[int] {40: new rec1( 100, "xyz" ) } };
    If not, why not?
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  7. #37
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    Looks like it -- well, once you add the type information to the literals, as follows:
    Code:
    item [int,int] imap = item[int,int]{4: item[int] {4: $item[eyepatch]} };
    
    record rec1 { int a; string b; };
    
    rec1 [int,int] rmap = rec1[int,int]{4: rec1[int] {4: new rec1( 10, "abc" ) }, 10: rec1[int] {40: new rec1( 100, "xyz" ) } };
    edit: I see, you're referring to omitting type specification entirely.

  8. #38
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    It certainly would be simpler to infer type from the lhs of the assignment. But this would primarily be useful in initializing variables. In the case of passing in literals as arguments to functions (which I always saw as the main use case of this feature), the current syntax might be the best we can do -- otherwise, overload resolution seems... potentially difficult. Not impossible, but probably more effort than it's worth.

  9. #39
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    10,530

    Default

    Well, yes. I am interested (at the moment) in initializing maps from literals. So, the type definition is redundant.
    For parsing arguments, the type definition is necessary, to disamiguate overloaded functions, at least.

    They don't have to have the same syntax requirements.
    Ph'nglui mglw'nafh Cthulhu
    R'lyeh wgah-nagl fhtagn.

  10. #40
    Developer
    Join Date
    Aug 2009
    Posts
    2,564

    Default

    Certainly. The current implementation was just simpler (and in practice, a neat side effect), since we got code reuse without any extra effort.

    Other than that one point, I don't see any other immediate issues. Given the structure of parseAggregateLiteral, you probably will be able to reuse that code (I imagine you could add an else-if around Parser.java:861, if you wanted to implement the notation without '=', which might even be marginally easier).
    Last edited by heeheehee; 01-11-2017 at 12:47 PM.

Similar Threads

  1. flyeredML - potential rounding problem
    By Magus_Prime in forum Scripting Discussion
    Replies: 40
    Last Post: 02-17-2015, 01:38 PM
  2. Map literals
    By shademaster00 in forum Scripting Discussion
    Replies: 4
    Last Post: 02-12-2012, 05:43 PM
  3. 10018: Tweak ScriptMRUList for potential reuse.
    By RSS Bot in forum Latest SVN Changes
    Replies: 0
    Last Post: 11-21-2011, 05:40 PM
  4. set_auto_attack() Potential bug?
    By Banana Lord in forum Community Support
    Replies: 4
    Last Post: 06-14-2011, 06:51 AM
  5. Feature Potential Earnings (actual)
    By NardoLoopa in forum Bug Reports
    Replies: 9
    Last Post: 09-07-2010, 08:26 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •