Feature - Implemented print()++

F

fredg1

Member
You know how, when you do "ash <command>" on the CLI, if you end with a record or an aggregate, mafia will tell you the content of the record/aggregate? Print now does that, always.

1st, this moves the "dump" function that was in AshSingleLineCommand.java and puts it in RuntimeLibrary.java (AS PUBLIC; trying to make sure I get your attention here, Veracity, to be sure you're not against that).


2nd, the two print functions now accept any datatype. If they get sent a string, they print it, as normal, and the function ends. If it's NOT a string, they turn it into a string, and sends it back to them. Then, they look at the datatype of what they initially had, and if it's a composite, they send it to dump() (which now supports colors, too!).

Proof of concept: javaw_LsZ5WoEd4b.png

I'm pretty sure there's things that can be improved, such as taking care of the cleaning of the color's string at the start and only passing "that" around, but I'm... currently quite eager to go to sleep, so I'll put this here, let you guys look at it and leave feedback, and if there's anything wrong, I can take care of it tomorrow. G'night (well... it's almost 8Am... :| )

View attachment .patch
 
fredg1 said:
If they get sent a string, they print it, as normal, and the function ends. If it's NOT a string, they turn it into a string, and sends it back to them
Click to expand...

I had an error in expectations concerning print(a + b) when a and b were both integers. I was expecting that print would see two integers and an addition operator but what was happening was two integers were coerced into strings and then concatenated. Does this patch change, perhaps inadvertently, that behavior?
 
I would expect all these to produce the same result:
Code: 
string s1 = 2 + 2;
int two = 2;
string s2 = two + two;
print(s1);
print(s2);
print(2+2);
print(two+two);
And they do: 4. I can understand expecting them all to produce 22, but I don't like that. Print certainly shouldn't be special.
 
fronobulax said:
I had an error in expectations concerning print(a + b) when a and b were both integers. I was expecting that print would see two integers and an addition operator but what was happening was two integers were coerced into strings and then concatenated. Does this patch change, perhaps inadvertently, that behavior?
Click to expand...

javaw_8RV7blSHRl.png

This seems to already be the normal behavior?? If not, you'll need to be more specific on the context.
 
Sorry. I'm having real trouble with written English today.

I am looking for reassurance that this will not change existing behavior, specifically precedence relationships involving coercion and and operators in print statements.
 
Additionally, two things.

First: if you notice, on the image I attached in my previous message, you can see that the "print" functions (as well as "to_json") now say "null" as their expected value when using "ashref".
This comes from THIS: View attachment 9768

Should it be changed to "any"?



Second: I noticed that in my new/modified version, whenever I input a CLI command, a full extra linebreak is added at the end, whereas only a few pixels were added previously.
(short video which I hope clarifies what I mean)
I can't seem to get what change I made could possibly cause this.
 
fronobulax said:
Sorry. I'm having real trouble with written English today.

I am looking for reassurance that this will not change existing behavior, specifically precedence relationships involving coercion and and operators in print statements.
Click to expand...

If we're ever going to break old scripts (which we do!) this seems like a very reasonable behaviour to change.
 
I... don't think that way?

An integer + an integer should give a new integer, even if the addition is done "on top" of a function that expects a string...
 
Take a look at Implicit conversion to strings.

Here is tbl.ash::

Code: 
// This data structure is an easier to use representation of KoLmafia's
// string representation in _beachLayout. It maps row number (an int) to
// 10-character string of squares, coded as above

typedef string [int] beach_layout;

// Function to convert a string compatible with the _beachLayout
// property to a beach_layout map

beach_layout to_beach_layout( string squares )
{
    beach_layout layout;
    foreach i, row_data in squares.split_string( "," ) {
	int colon = row_data.index_of( ":" );
	if ( colon != -1 ) {
	    int row = row_data.substring( 0, colon ).to_int();
	    string squares = row_data.substring( colon + 1 );
	    layout[ row ] = squares;
	}
    }
    return layout;
}

// Function to convert beach layout map into a string compatible with
// the _beachLaout property

string to_string( beach_layout layout )
{
    buffer value;
    foreach row, squares in layout {
	if ( value.length() > 0 ) {
	    value.append( "," );
	}
	value.append( row );
	value.append( ":" );
	value.append( squares );
    }
    return value.to_string();
}

string test = "2:rrrrrrrrrr,3:rrrrrrrrrc,4:rrrrrrrrrr,5:rrrrrrrrrr,6:rrrrrrrrrr,7:rrrrrrrrrr,8:rrrrrrrrrr,9:crrrrrrrrr,10:rrrrrrrcrr";

beach_layout layout1 = test.to_beach_layout();
print( layout1.to_string() );

beach_layout layout2 = test;
print( layout2 );
Here is the result of invoking that script:

Code: 
[color=green]> tbl.ash[/color]

2:rrrrrrrrrr,3:rrrrrrrrrc,4:rrrrrrrrrr,5:rrrrrrrrrr,6:rrrrrrrrrr,7:rrrrrrrrrr,8:rrrrrrrrrr,9:crrrrrrrrr,10:rrrrrrrcrr
2:rrrrrrrrrr,3:rrrrrrrrrc,4:rrrrrrrrrr,5:rrrrrrrrrr,6:rrrrrrrrrr,7:rrrrrrrrrr,8:rrrrrrrrrr,9:crrrrrrrrr,10:rrrrrrrcrr
This works because:

1) print( string ARG )
2) ASH will look up custom to_string( TYPEDEF ) and to_TYPEDEF( string ) functions.
3) When assigning to a string (or typedef or record) as a variable or function parameter, ASH will auto-coerce using such custom functions.

Your proposal to change the signature of print() to no longer have a string argument will break this test - and any other script that depends - by eliminating this auto-coercion.

This is a non-backwards-compatible change that will break MY scripts. Therefore, I don't like it.

Adding a new runtime function with the "dump" functionality seems OK.
Breaking print() is not.
 
Veracity (of course) has put it very convincingly. I think creating a new function and naming it dump is a good idea moving forwards.
 
fredg1 said:
Still waiting for a response/review; did I not do things correctly?
Click to expand...

Huh?

Veracity said:
Adding a new runtime function with the "dump" functionality seems OK.
Breaking print() is not.
Click to expand...

I had not realized you were continuing anyway.

Just calling it ".patch" doesn't really emphasize to me that there is a file behind the link. My bad but dump.patch might have caught my attention.

A 30 second look at the patch but not applying it suggests to me that it still contains the changes to print that were objected to. I can look harder to confirm that, but a post that was a little more verbose and acknowledged some of the proposal had been dropped would have gotten my attention sooner.
 
My opinion is probably near-irrelevant, but I'd just like to add that I've been playing around with the dump command, and it's been really helpful to me when I'm experimenting with scripts. Nothing earth-shatteringly important, but I find the data structures a little confusing at times and being able to 'dump' them out and see what they contain without having to iterate over everything has been really helpful.

Technical issues aside, concerning which I accept that the opinion of the developers is paramount, if anyone's wondering whether there's any desire for such a command I'm happy to put my hand up and say I'd love to see this incorporated officially, and it's been really helpful to me.
 
It looked like there was some refactoring of print to extract the “add color” part so that dump could use it. To be honest, I don’t understand why you’d want to dump in red, say, but meh. I’ll look at it a bit more and submit (something like) it.
 
dump doesn't act as an unknown command in the gCLI, but isn't in help.

ash dump() works as expected, but it shouldn't be callable the way I did it in the first instance. It probably doesn't make sense if you don't have records to dump.

Code: 
> dump

[COLOR="#FF0000"]Internal error: Illegal type for main() parameter[/COLOR]
> dump rotgut

Bad null value: "rotgut"
Returned: null

> dump X

Bad null value: "X"
Returned: null
Expected unknown command:
Code: 
> ribbit

[COLOR="#FF0000"]Unable to invoke ribbit[/COLOR]

Code: 
> [COLOR="#DAA520"]ash record rec{string a;int b;float c;} y= new rec("aaa",10,10.5),z = new rec("bbb",30,9.9);rec[int] map = {0:y,1:z};dump(map,"red")[/COLOR]

[COLOR="#FF0000"]aggregate rec [int]
0 => record rec
  a => aaa
  b => 10
  c => 10.5
1 => record rec
  a => bbb
  b => 30
  c => 9.9[/COLOR]
Returned: void
 
Last edited:
You must log in or register to reply here.
Back
Top