Skip to content

Conversation

@JaroslavTulach
Copy link
Member

@JaroslavTulach JaroslavTulach commented Sep 24, 2025

Pull Request Description

Important Notes

  • coming from Java with its Object.toString - one might be fine with to_text in Any
    • however pretty and to_display_text clearly seem weird
  • moreover my object oriented roots are in Turbo Pascal 5.5
    • the root object there - the TObject had no methods at all!
    • while clean (e.g. Turbo Pascal was no "something oriented language", but trully just an object oriented language) - I don't call for that in case of Enso
    • ultimatelly I'd like Enso to be "conversion oriented language" - e.g. Any.to is perfectly fine in the root type
  • with all the extension method capabilities Enso has, I believe moving to_display_text, pretty out of Any is a completely legitimate goal

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • All code follows the style guide.
  • API tests have been updated.
  • Unit tests continue to pass.
  • Extra nightly tests are fully green.

@JaroslavTulach JaroslavTulach self-assigned this Sep 24, 2025
@JaroslavTulach JaroslavTulach changed the title Defining to_text & co. as extension methods Defining to_text & co. as extension methods Sep 24, 2025
@github-actions github-actions bot added the -libs-API-change-Base Marks a PR that changes the public API of Standard.Base label Sep 24, 2025
Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to need to add from project.Data.Text.Extensions import all to a lot of files in Standard.Base.
Think about 57 files need it added,

@JaroslavTulach
Copy link
Member Author

Going to need to add from project.Data.Text.Extensions import all to a lot of files in Standard.Base. Think about 57 files need it added,

  • why do we need to add such imports?
  • all the tests seem to be green?
  • is there some other test that's failing and I should fix it?

@jdunkerley
Copy link
Member

Going to need to add from project.Data.Text.Extensions import all to a lot of files in Standard.Base. Think about 57 files need it added,

  • why do we need to add such imports?
  • all the tests seem to be green?
  • is there some other test that's failing and I should fix it?

Take Random.enso it has a call to make a uuid: uuid self = UUID.randomUUID.to_text
Guessing we don't have a test on this method (our coverage is slowly improving but far from 100%).

This would have worked previously but will now error as this code does not import Text extensions.

@jdunkerley
Copy link
Member

jdunkerley commented Sep 26, 2025

Ones I suspect (but maybe false positives):

  • distribution/lib/Standard/Base/0.0.0-dev/src/Any.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Array.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Index_Sub_Range.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Interval.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/List.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Maybe.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Number_Utils.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Numbers.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Range.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Read/Many_Files_List.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Read/Return_As.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Regression.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Statistics.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Case_Sensitivity.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Encoding.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Text_Ordering.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Text_Sub_Range.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Time/Date_Range.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Time/Date_Time_Formatter.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Time/Time_Zone.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Data/Vector.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Enso_Cloud/Enso_User.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Enso_Cloud/Errors.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Enso_Cloud/Public_Utils.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/Common.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/Empty_Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/File_Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/No_Such_Key.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/Time_Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Errors/Wrapped_Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Function.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Array_Like_Helpers.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Context_Helpers.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Instrumentor.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Rounding_Helpers.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Time/Format/Analyzer.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Time/Format/As_Java_Formatter_Interpreter.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Meta.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Metadata.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Network/HTTP/HTTP_Error.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Panic.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Random.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Runtime/Source_Location.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/Advanced/Restartable_Input_Stream.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/Encoding/Encoding_Resolver.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File/Advanced/Temporary_File.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File/File_Access.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File/Generic/File_Like.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File/Generic/Writable_File.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/File/Local_File_Write_Strategy.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/Process/Exit_Code.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/System/Process/Process_Builder.enso
  • distribution/lib/Standard/Base/0.0.0-dev/src/Widget_Helpers.enso

@JaroslavTulach
Copy link
Member Author

Ones I suspect (but maybe false positives):

  • I was also expecting bunch of failures
  • but apparently the CI is green enough
  • somehow the Any.to_text method must become available without changing the imports...

@JaroslavTulach JaroslavTulach added the CI: Ready to merge This PR is eligible for automatic merge label Oct 7, 2025
@JaroslavTulach
Copy link
Member Author

JaroslavTulach commented Oct 7, 2025

  • somehow the Any.to_text method must become available without changing the imports...

I am trying to run:

main n=10 = n.to_text+n.to_text

and it continues to work. Why? Because builtin methods are still registered:

"main"
	at org.enso.interpreter.runtime.TruffleCompilerModuleScopeBuilder.registerMethod(.java:112)
	at org.enso.interpreter.runtime.builtin.BuiltinsRegistry.lambda$registerBuiltinMethodsLazily$3(:326)
	at org.enso.interpreter.runtime.builtin.BuiltinsRegistry$$Lambda/0x000072aea32a1938.accept
	at java.util.HashMap.forEach(HashMap.java:1430)
	at org.enso.interpreter.runtime.builtin.BuiltinsRegistry.registerBuiltinMethodsLazily(BuiltinsRegistry.java:319)
	at org.enso.interpreter.runtime.builtin.BuiltinsRegistry.<init>(BuiltinsRegistry.java:56)
	at org.enso.interpreter.runtime.builtin.Builtins.<init>(Builtins.java:114)

that includes also Any.to_text method:

image

Thus technically we are changing very little by moving the definition to extension methods. It just looks differently (and hopefully better from API perspective), but behaves as it used to. A rewrite of how we deal with builtin types is left for another PR exercise.

@mergify mergify bot merged commit 7d3e1eb into develop Oct 9, 2025
159 of 165 checks passed
@mergify mergify bot deleted the wip/jtulach/AnyNoToText branch October 9, 2025 15:36
mergify bot pushed a commit that referenced this pull request Oct 12, 2025
Enso, at it roots, is a **conversion oriented language**. Enso supports flexible definitions of conversions of values of a type to another. To stress the importance of conversions in usage of the Enso language, there is `Any.to target_type` method available on any value in the Enso system that allows to _morph and view any object as a different type_ easily when such a conversion is available.

In addition to that Enso is **structured equality oriented language**. There is `Any.==` operator that allows any two values to be compared for equality. The comparison is based on structure - e.g. two instances of the same atom with equal fields are the same. Enso provides such a _structured equality_ implementation to every user defined type automatically, yet it also offers more complex equality handling when needed (via `Comparable` type).

Enso is **conversion and** (structured) **equality oriented language**. That fact is stressed by the shape of its root type `Any`. It exposes just `.to`, `==` and `!=` operations.

# Important Notes
- To fulfill the promise of Enso being  **conversion and equality oriented language**
- this PR proposes to turn `Nothing` related methods into _extension methods_
- e.g. to move them out of `Any` type into `Nothing` type
- the change is supposed to be compatible for everyone using `from Standard.Base import all`
- this PR is the final step finishing the work previously started by
- #14004
- #14003
- #13978
- #14017
- #14050
- in the tradition of those PRs let's argue:
- it is better to be somebody, or at least anybody - nobody wants to feel like `Nothing`
- hence we don't want Enso to feel like "nothing oriented language"
- as such `Nothing` related methods should be provided only as extension methods!
- on a more technical note: `obj.is_nothing.not` can actually be written as `obj!=Nothing`, not sure why we prefer the former (and longer) variant? Maybe some FP bias!?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

-libs-API-change-Base Marks a PR that changes the public API of Standard.Base CI: Ready to merge This PR is eligible for automatic merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants