crystal-lang/crystal

The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/

From IRC (bridge bot)

@FromIRC

<Papierkorb> The latter because you have pretty good access to the AST if passed as argument

@marceloboeira

interesting that, given a default name of a class (upper camelcase), I can't define a macro with a similar structure. e.g.:

class Foo; end

macro FooBar(value)
...
end

FooBar("foo")

... expecting token 'CONST', not 'nil'

even if I don't have a class with the same name, which would be understandable...

Ghost

@ghost~55586c4815522ed4b3e08557

a macro name, like methods should start with a lowercase letter

a word starting by an upper case letter is recognized as a CONST (a type, a constant, ..)

@marceloboeira

:+1:

but is that because of the order of evaluation of the macro?

Ghost

@ghost~55586c4815522ed4b3e08557

the conventions are explained here: https://crystal-lang.org/docs/conventions/coding_style.html

no it has nothing to do with the order of execution, but with the parser: FooBar(...) is recognized as a generic type (like Array(String))

and it mess up something when trying to parse it

@marceloboeira

I thought maybe the macro expansion happened before the rest of the evaluation/parsing. But it makes sense to happen after considering that you need to check the types

From IRC (bridge bot)

@FromIRC

<oprypin> that's the magical part

<oprypin> macros need to be evaluated before everything but also after everything :⁠D

<oprypin> in simple cases macros are evaluated before everything, but for example if you refer to the current type in the macro, that delays the expansion until the type's semantics are figured out

@marceloboeira

macros need to be evaluated before everything but also after everything :⁠D
http://www.reactiongifs.com/wp-content/uploads/2013/10/tim-and-eric-mind-blown.gif

@marceloboeira

https://github.com/marceloboeira/option.cr

From IRC (bridge bot)

@FromIRC

<Papierkorb> Why

@marceloboeira

just experimenting, I wanted to do it with macros, but then I've realised that it does not make any sense considering that you might have dynamic results

From IRC (bridge bot)

@FromIRC

<Papierkorb> For real code, you'd just rely on Nil

<Papierkorb> In your example, it'd simply be a Unsafe.new.io || "Empty..."

Cris Ward

@crisward

Just need 4,027 more stars to overtake ruby... https://github.com/showcases/programming-languages :wink:

@marceloboeira

But considering everything can be nil,
Unsafe.new.io.foo.bar
you would have to

(((Unsafe.new.io || "default").foo) || "default_2").bar

From IRC (bridge bot)

@FromIRC

<Papierkorb> No

<Papierkorb> Everything can't be nil

@marceloboeira

not everything, but the calls to unsafe things

IO related

From IRC (bridge bot)

@FromIRC

<Papierkorb> That's the whole point. Nil is a type on its own in Crystal. Try this: def foo(a : String); a; end; foo(nil) - Won't work

<Papierkorb> ..huh

<Papierkorb> IO is a type. If you expect an IO, or pledge to return an IO, you can only return that, no nil

<Papierkorb> Impossible. If you do find a way, it's a serious compiler bug

<RX14> if you do find a way you'll get segfaults lol

<Papierkorb> The only way to 'escape' having to return something matching the method prototype is raising an Exception. Another common theme is something like this: def read_input : String?; ...; end. It may return a String, or nil. In this case, the compiler will force you to work with the result in a type-safe manner

@marceloboeira

e.g.:

User.where(foo: "bar").first.name

will never be nil?

From IRC (bridge bot)

@FromIRC

<Papierkorb> If #where, #first and #name are not nil-able, never.

<RX14> @marceloboeira have a pay with nil, you'll find out what works and what doesn't.

@marceloboeira

you mean because of the nilable String?, ok, fair enough

From IRC (bridge bot)

@FromIRC

<Papierkorb> The type system of Crystal alone safes you from having to clutter your code with Just(x) etc.

John Jansen

@johnjansen

ok people, can someone point me at the solution to this on Ubuntu 16.04.2 LTS

$ crystal build test.cr --release
crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102:  7523 Aborted                 (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"

From IRC (bridge bot)

@FromIRC

<Papierkorb> That is a compiler crash

<Papierkorb> Can you share the code?

Nick Franken

@fridgerator

@johnjansen its an issue with the latest build

crystal-lang/crystal#4719

John Jansen

@johnjansen

thanks @fridgerator, i feel another broken record coming on ;-)

Nick Franken

@fridgerator

lol

nah there is a workaround for this one

add --no-debug

John Jansen

@johnjansen

thanks, reading all that would have taken an age

Cris Ward

@crisward

@johnjansen Just tried compiling with --release and --no-debug and I'm get a strange bug where my app doesn't recognise '/' as a path. Will try and isolate the specific bug tomorrow.

John Jansen

@johnjansen

interesting

Cris Ward

@crisward

It's fine without --release, which means it's probably something to do with an llvm optimisation.

Where communities thrive

People

Repo info

Activity