Feature - Implemented print()++

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
 

fronobulax

Developer
Staff member
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

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?
 

Crowther

Active member
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

Developer
Staff member

fredg1

Member
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?

javaw_8RV7blSHRl.png

This seems to already be the normal behavior?? If not, you'll need to be more specific on the context.
 

fronobulax

Developer
Staff member
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.
 

fredg1

Member
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.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
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.

If we're ever going to break old scripts (which we do!) this seems like a very reasonable behaviour to change.
 

fredg1

Member
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...
 

Veracity

Developer
Staff member
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.
 

gausie

D̰͕̝͚̤̥̙̐̇̑͗̒e͍͔͎͈͔ͥ̉̔̅́̈l̠̪̜͓̲ͧ̍̈́͛v̻̾ͤe͗̃ͥ̐̊ͬp̔͒ͪ
Staff member
Veracity (of course) has put it very convincingly. I think creating a new function and naming it dump is a good idea moving forwards.
 

fronobulax

Developer
Staff member
Still waiting for a response/review; did I not do things correctly?

Huh?

Adding a new runtime function with the "dump" functionality seems OK.
Breaking print() is not.

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.
 

Veracity

Developer
Staff member
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.
 

MCroft

Developer
Staff member
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:
Top