Something is really strange with the compiler specs using Path...

The support/syntax helper includes Crystal into the top level namespace, so all over the specs Path is used to reference Crystal::Path. Now, the top level type ::Path overwrites that and of the specs no longer compile because types mismatch.

With 5ff295d I tried to replace Path with qualified Crystal::Path to use the correct type.
There are however some strange issues with some specs, for example spec/compiler/macro/macro_methods_spec.cr:1209:

assert_macro "x", %({{x.inputs}}), [ProcNotation.new([Crystal::Path.new("SomeType")] of ASTNode, Crystal::Path.new("SomeResult"))] of ASTNode, "[SomeType]"

This line produces a syntax error: expecting identifier 'class', not 'new'.

Previously it worked with Path.new. I can't really see what's the issue here... ist there any special syntax related to that example?

@straight-shoota

[] of X, Y -> Z

That's an array of procs.

Problem is, if you write

foo x, [] of X, Y

then compiler will think X, Y... refers to the type of the upcoming block, which never comes.

Solution: use parentheses:

foo x, ([] of X), Y

But why is this an issue? The change just replaces Path with Crystal::Path...

I'd suggest changing name to Pathname as in Ruby since it clearly tells you the purpose of this Class, Path is IMO way too generic (hence collision with Crystal::Path).

Pathname is just ugly... And its longer for what is hopefully a very well used class.

We just need not to include Crystal in our specs.

The language is ugly regarding types, there are no nice "imports" and no way to prevent types leaking all over the global namespace. We just have to accept that and move on.

@asterite I think it's ok to include Crystal only for compiler specs, I don't think it's useful anywhere else.
For this we'd need to compile specs one category at a time (std, then compiler, then integration, etc..). I think this has also other advantages other than better controlling global namespace pollution, like less memory needed to build&run specs.

@bew problem is, Path will be required by prelude (it's used in File, which is required by prelude), so including Crystal will create a conflict with Path.

Can't we just put the specs in Crystal namespace? That way Path would point to Crystal::Path (ASTNode) and Path (file system path) could by accessed as ::Path.

I still don't understand why the parsing changes based on the addition of a qualifying name space.

You can have imports using private alias at the top level but you're always going to have a prefix.

I'm fine with putting the specs in a module.

Now I don't think the parsing changes or has anything to do with what I said above. I'll checkout this branch and investigate.

Found it. If you do:

foo([] of T, Y.new)

it parses "well" (Y.new) is a separate argument. The compiler will try to check if what comes after a comma can be a type, but because .new follows it's not.

However, with:

foo([] of T, X::Y.new)

the compiler fails to see this, because of the ::. We are just missing that rule in the parser.

Would be good to get some more design opinions on this PR from the core team. I'm not fond of putting so much behaviour on the Type enum...

The more types we add to the std that's loaded by default (and Path will be one such type), the longer it takes to compile an empty file. So until we resolve that (and I'm more and more inclined to change the language for good) I can't comment on this. Well, my initial reaction is that I needed needed a Path type. I do need to split a path, or get the extension, or the base name, but all of that already exists as File class methods. Maybe they could be moved to a Path type, but meh.

but all of that already exists as File class methods

The obvious response to that is that path operations tend to be composed quite often, and providing a path type makes composing these operations a lot easier because you don't have to specify File. every time.

I'm not particularly sympathetic to the compile time argument - I think that Path is one of the few things missing from the corelib, and after that is there really anything left to add?

Things like deque and set belong in the corelib less than path, but they're required by other parts of the corelib.

because you don't have to specify File. every time

Having to type less is never a good argument in my opinion (or at least I also thought like that, but not anymore)

I think that Path is one of the few things missing from the corelib, and after that is there really anything left to add?

• A precise GC
• Multithread support (whatever that is), with operations to simplify coding (work groups, sync operations, etc.)
• printf is not yet good/complete in my opinion
• I also always wanted to have scanf (I did a quick proof of concept in the past and it worked, though I think it won't work anymore with how I reimagine the language)
• And possibly other things I might be forgetting

Having to type less is never a good argument in my opinion

No, having to type less is never a good reason to sacrifice readability or understandability (i.e. adding too much magic), but here we do neither. The only thing we sacrifice for having to type less is adding a new class to the stdlib. Considering the current File primitives are demonstrably woefully inadequate on windows, and we'd have to basically rewrite them all anyway (see file_spec.cr in #5623), why not migrate to using Path at the same time.

A precise GC

will be written in C, rust (unlikely), not crystal. It's a GC'ed language itself - it's not suited for writing a GC.

Multithread support (whatever that is), with operations to simplify coding (work groups, sync operations, etc.)

fair enough, although I feel a lot of the higher-level concurrency abstractions can be in the stdlib not the corelib

printf is not yet good/complete in my opinion

That's more code, but not really a whole new class. If the code is only string ops and maths, then it will not be instantiated more than once, and will contribute much less to compile times.

I also always wanted to have scanf (I did a quick proof of concept in the past and it worked, though I think it won't work anymore with how I reimagine the language)

I don't think this is a good idea, writing lightweight parsers by hand is super easy in crystal, usually more robust, and generate better errors.

will be written in C, rust (unlikely), not crystal. It's a GC'ed language itself - it's not suited for writing a GC.

Go's GC is written in Go ;-)

Go also doesn't have numerous places where hidden allocations occur. Even ones you wouldn't think about like .as.

Can we please keep this thread clear of discussions about GC implementations and other Stdlib features? The gist is: this adds an additional type to corelib. We're also pretty sure that there will be no or only very few additions to that in the future. Having the class makes many things easier to write, but on the other hand adds an additional type to the inference algorithm for every program.
That's a trade-off to consider.

@RX14 I agree that having the behaviour defined on the enum is not great. It can easily be moved to private methods on Path, maybe with just a little bit more to type. Anyway, that's just an implementation detail.

There should be no breaking changes here so this should be fine for 0.27.1

There is technically a minor breaking change in File.expand_path which now preserves trailing slashes. If that's a hold back we could just revert the refactoring of that specific method - or all File methods for that matter. The focus should be on getting Path in the stdlib.

@bcardiff this is still blocking a lot of Windows specs, i'd love it reviewed and merged in the next 2 weeks so I can resume working on Windows over Christmas.

Any chance this PR will make it into 0.27.1?

No, there are breaking changes to File class methods. It's already milestoned for 0.28.0 and needs a review from @bcardiff
I've rebased and squashed on current master.

@straight-shoota Thank you.

Thanks, @r00ster91. Fixed typos and rebased on master.

Yeah, can't believe i's been over a year... 🤣