Just published the first V example to show you some features of the language. Very interested in your input. #3

medvednikov · 2019-02-15T20:07:18Z

Very interested in your input.

https://github.com/vlang-io/V/blob/master/examples/users.v
https://github.com/vlang-io/V/blob/master/examples/hello_world_gui.v
https://github.com/vlang-io/V/blob/master/examples/generic_repository.v

ducdetronquito · 2019-02-19T09:42:48Z

Hi @medvednikov !

My answer will be off-topic: I just wanted to thank you for what you are doing with Volt and V, both look very promising !

I see a huge amount of feature requests, and I just wanted to say: Take your time, good softwares takes time. It's easy to get overwhelmed building Free softwares: sometimes it's better to say "no" or "not for now" in order to build great things in the long run :)

Have a good day !

xorhash · 2019-02-21T18:58:13Z

Here's an assortment of thoughts:

From a Ruby and C background, I quite appreciate constants having to be uppercase. It also helps grepability (you know that you have to grep 'const CONSTANT_HERE' -r * if you want to find the value of a constant).

You may already want to put special thought into the HTTP library since I assume it will see a lot of usage. In particular, you may want to support both synchronous and asynchronous patterns; consider some standard library way to event loop all kinds of networking.

I enjoy the design of the or keyword and how you can immediately force a return. However, I'm not sure if an implicit $err is always the right solution. I'm worried about localization and internationalization of error messages in particular.

How do you return failure from main? This isn't as much of a concern on Windows and for GUI applications, but your example doesn't seem to address a case like int main(void){return EXIT_FAILURE;} in C. I'm also rather happy about eprintln() existing; you may, however, want to look at the BSD err(3) family, which print a message to stderr and then exit with the given exit status.

I'm not sold on having both ' and " as string delimiters with no semantic change. I know that Python does that, but considering UNIX Shell, Perl and Ruby all consider ' to be special in prohibiting variable expansion, you might want to do the same.

Looking at the printing examples: Is it accurate that a variable identifier can be any character.

What happens if you try to println() an array type? My intuition would suggest that a compilation error would have the least surprise, but you may want to do something else.

What even is an int? Is that a literal C int with all the risks of undefined behavior on signed overflow? Are unsigned types even available? Sun's experience with Spring (the OS from the 90s, not today's Java framework) showed that you kind of need unsigned integers for writing device drivers.

Are you making any guarantees about the C code output of a function that only does arithmetic on integer types and has no branching? This may be relevant for the implementation of cryptographic algorithms in particular.

Concurrency remains an open issue to address in another example, too, probably.

medvednikov · 2019-02-21T19:23:37Z

Hi @xorhash

Thanks a lot for your detailed feedback!

You may already want to put special thought into the HTTP library since I assume it will see a lot of usage.

Absolutely!

How do you return failure from main?

Just like in go: os.exit(1)

However, I'm not sure if an implicit $err is always the right solution. I'm worried about localization and internationalization of error messages in particular.

err value is set with return error(error_msg). Error message can be fetched via gettext for example.

Looking at the printing examples: Is it accurate that a variable identifier can be any character.

Can you explain what you mean?

What happens if you try to println() an array type? My intuition would suggest that a compilation error would have the least surprise, but you may want to do something else.

println supports everything that has a str() method. Arrays have that predefined.
So println([1,2,3]) will print [1, 2, 3] :)

What even is an int? Is that a literal C int with all the risks of undefined behavior on signed overflow? Are unsigned types even available?

Very good question. This will be one of the first topics in the docs. V has byte, i16, int, i64, u64 etc.

int is not like in Go or C. It's always an i32. I just personally prefer int to i32. It's used in approximately 80% of cases in Go stdlib, so I made an exception for it. It goes against the philosophy of the language, but I really like having int instead of i32.

Are you making any guarantees about the C code output of a function that only does arithmetic on integer types and has no branching?

Could you please give an example?

Thanks

medvednikov · 2019-02-21T19:25:57Z

Or did you mean what happens if we call print([]User)? Compilation error :)

medvednikov · 2019-02-21T19:28:46Z

As for ', I want to have only one main way of denoting strings. V will automatically replace " with ' if there are no apostrophes in it.

I might remove " entirely and force developers to just escape apostrophes.

' strings can have $vars and newlines, unlike all other languages, yes.

burlesona · 2019-02-21T19:39:24Z

Just curious, why not go the other way with strings, and only use double quotes?

That seems more cross language consistent as it means you get variable interpolation etc., and in my experience apostrophes are much more common in strong literals than double quotes, so if you’re going to pick one the double quotes will require less escaping.

burlesona · 2019-02-21T19:41:23Z

Also, off topic, but since the above is my first post on your project I just wanted to say hello! V looks fantastic, take the good stuff of Go and make it even better (to me anyway).

Would love to help if there’s any way I can. Please let me know :)

emidoots · 2019-02-21T19:45:34Z

Will you keep raw string literals (backticks) from Go?

medvednikov · 2019-02-21T19:48:27Z

@burlesona JSON is very popular right now, and it has lots of ".

Also to me ''s look cleaner in the code and don't require shift.

But I had your exact thoughts, maybe I'll do that. Just to be consistent with other languages.

@slimsag ' behaves exactly like ` in Go.

burlesona · 2019-02-21T19:58:28Z

@medvednikov yeah it’s kind of tricky to balance, I think this is why most languages have a few string literal options :)

Maybe a block string literal syntax like Ruby’s heredoc (or many other examples) is a viable alternative for things like JSON input? But it does result in more than one way to make a string, which I agree isn’t perfect.

Or finally, less easy to type, but you could just go straight for backticks or some other universal string delimiter.

emidoots · 2019-02-21T20:02:01Z

@medvednikov Not true -- ' is a rune literal in Go and cannot contain multiple characters nor newlines and supports escape codes, in contrast ` is a raw string literal supporting multiple characters and newlines with no support for escape codes

oliwer · 2019-02-21T21:12:05Z

Hello @medvednikov and congratulations for V! It seems to solve many of Go's issues and could be a nice "better C". A few questions:

since your functions are all lowercase, how do you differentiate between local and exported functions?
can you tell us more about the what the runtime will do and how do you handle memory management compared to Go?
how do you declare a character/rune if ' is for strings? I understand that typing " is impractical with your keyboard, but you're a minority. Best thing you could do is switch ' and ", but I guess most people would hate it.
the error handling handling looks great! I also wanted to use or as that's what we often use in perl.
will V handle generics?

medvednikov · 2019-02-21T21:33:06Z

Hi @oliwer

since your functions are all lowercase, how do you differentiate between local and exported functions?

It's going to be either pub or some symbol like in Oberon.

can you tell us more about the what the runtime will do and how do you handle memory management compared to Go?

There's no runtime, memory management will be similar to Rust.

how do you declare a character/rune if ' is for strings? I understand that typing " is impractical with your keyboard, but you're a minority. Best thing you could do is switch ' and ", but I guess most people would hate it.

Backticks are used for characters. Which feels a bit weird.

Are there keyboard layouts that don't require shift to write "?

the error handling handling looks great! I also wanted to use or as that's what we often use in perl.

Thanks! I did some Perl in the past, that might have influenced the syntax :)

will V handle generics?

It already does.

emidoots · 2019-02-21T21:46:29Z

Would be cool to see an example of generics somewhere!

boyter · 2019-02-22T01:45:29Z

+1 to seeing some example of generics.

rrjanbiah · 2019-02-22T11:20:17Z

OT: Will it be possible to convert Go code to V?

medvednikov · 2019-02-22T12:20:44Z

@slimsag @boyter I'll add an example with Generics soon.

@rrjanbiah yes, but coroutines and channels have to be implemented first.

International · 2019-02-22T13:03:45Z

Hi @medvednikov , does volt also use generics in it's codebase? Does it affect the compile times much?

medvednikov · 2019-02-22T13:25:37Z

@International no.

V compiler used to rely on generics to implement arrays and maps, but then I replaced them and made the code smarter (similar to Go's slices and maps).

There will be a way for users to create their own generic containers without generating extra code for each type and slowing down compilation time.

medvednikov · 2019-02-22T14:33:29Z

I've added an example with generics:

https://github.com/vlang-io/V/blob/master/examples/generic_repository.v

haltcase · 2019-02-22T22:20:57Z

I think it looks pretty good. I like a lot of the semantic choices you've made even if I don't particularly like some of Go's syntax that you're inheriting. I'm sure I'd get used to it though (except []User vs User[] that'll drive me insane 😆).

Immutability and first-class optionals (T?) with those nifty or blocks are great. I'm not sure I fully understand the way the or block works though. Do you always have to return from the outer function? How do you just do default values, or equivalents for some of Rust's Option methods?

It's going to be either pub or some symbol like in Oberon.

Either of these is good IMO, I don't like Go's capitalization rule for exports.

Backticks are used for characters. Which feels a bit weird.

It's probably best to use double quotes for strings and single quotes for characters but I understand the ease of typing isn't great for you. I use single quotes in JavaScript/TypeScript all the time but with everything else I code in using doubles, it can be a bit of a context switch.

Is there any short lambda syntax? (a, b) => a + b

How about pattern matching? It's one of my favorite features in Rust and ML languages, especially F#.

Is this a typo in the generic example? Should retrieve be find_by_id here:

https://github.com/vlang-io/V/blob/50d81e6edf1b7ed3c1ba0e24ce2c4b659b648b5a/examples/generic_repository.v#L34

medvednikov · 2019-02-23T01:44:23Z

Hey @citycide

Thanks for your feedback!

Is this a typo in the generic example?

Yes, I initially called it retrieve :) Fixed.

Do you always have to return from the outer function? How do you just do default values, or equivalents for some of Rust's Option methods?

Can you write a small example?

Is there any short lambda syntax? (a, b) => a + b

Not yet. Most likely there will be one. Need to think about the details.

How about pattern matching? It's one of my favorite features in Rust and ML languages, especially F#.

Same :)

Francesco149 · 2019-02-23T02:12:04Z

I'm very skeptical about the "400 KB compiler with zero dependencies" part. It just transpiles to C and then compiles with gcc/clang, doesn't it? that implies a dependency on gcc or clang. can the V compiler emit machine code by itself?

medvednikov · 2019-02-23T02:54:51Z

@Francesco149 this is a discussion about the syntax of the language.

V can compile to machine code directly, as well as to C.

dsnippet · 2019-02-23T03:17:51Z

Saw a couple of user examples that you published. V Looks interesting.
Since I could not get enough information from the user examples, here are some basic questions that come to my mind.

Does V (plan to) support OOP, inheritance, polymorphism etc?
Parallelism?
Systems Programming, as in support for pointers etc.
Garbage collection?

I would be glad if you can point me to some documentation.

dsnippet · 2019-02-23T03:35:17Z

Also ABI compatibility with C/C++. Is it possible to link in C/C++ functions directly in V?

medvednikov · 2019-02-23T04:27:05Z

@dsnippet

No, it will be exactly like Go. Structs, embedding, interfaces.
Yes. Again, same as Go.
Yes.
No.
Right now you can call any C function:
C.puts('hello world!')

awesomekyle · 2019-02-23T05:01:05Z

As someone who spends 98% of his time in C & C++ and has no experience with Go, any sort of "V for C Programmers" documentation would be very helpful. 😄 Looking forward to seeing V's release!

medvednikov · 2019-02-23T06:12:41Z

@awesomekyle V is language that can be learned in an hour.

A documentation/tutorial page will be out soon, and you'll see ;)

jkaye2012 · 2019-03-10T21:35:20Z

perhaps this genericity should be forbidden, and explicit handling of every single error required. I'd be all for it.

Sure, I'd be for that as well.

Explicit distinction may be required

Seems like something like that could work. I know it seems that you are against "declaring" errors before, but what if we take the idea that you're working with and say that the errors are always local to where the are defined. So the bare err always refers to your current context, but you can also reference that of others. Then we could write something like this:

fn foo()
{
  libraryA_bar(); // has error DoesNotWork
  libraryB_baz(); // has error DoesNotWork, but for completely different problem
  if err == libraryA_bar.err.DoesNotWork {
    ...
  } else if err == libraryB_baz.err.DoesNotWork {
    ...
  }
}

If we had qualified imports, this could be shortened to:

// pseudocode
import libraryA (bar)
import libraryB (baz)
fn foo()
{
  bar(); // has error DoesNotWork
  baz(); // has error DoesNotWork, but for completely different problem
  if err == bar.err.DoesNotWork {
    ...
  } else if err == baz.err.DoesNotWork {
    ...
  }
}

This seems to accomplish the namespacing without requiring pre-definition.

Just a note to highlight why the clash is important. This might seem far-fetched but I'm positive it would happen at least once if the language became very popular with out it. Keeping with our example above, let's say that libraryA.bar throws BadError and libraryB.baz doesn't throw anything. A user might handle things like this:

fn foo()
{
  libraryA_bar();
  libraryB_baz();
  if err == err.BadError {
    ...
  }
}

All good at the time it's written. Now let's say we update our dependencies. libraryA manages to completely remove its error via internal handling while libraryB adds BadError. Now your code will still compile, even though you thought you're supposed to be handling an error in bar, but now it's coming from baz!

I completely agree with regards to tooling. Though I would personally like to see those things implemented via something like LSP to prevent a single editor from ruling the language - np reason to not let people choose their tool for themselves!

PavelVozenilek · 2019-03-12T15:37:59Z

Warning: extremely long read!

I'd mentioned that I had toyed with an idea of designing language of my own. Allow me to list features of this hypothetical language, perhaps something could serve as an inspiration.

The language was intended to be similar to C (semicolons, {} brackets, C syntax kept where possible) and simpler than C (hopefully). I tried to stay away from all those complicated things promoted by academia.

More interesting features of the language:

1] typical source file would look like:

interface: // "interface:"  is keyword
...
... // declarations publicly visible outside the file
...
implementation: // "implementation:" is keyword
...
... // implementation of public functions + private helper functions
...

I was inspired by Turbo Pascal. This model would replace C headers, while still keeping their advantage (they clearly show what is exported).

Order of declarations was important:

interface:

fn A ...
fn B ...
fn C ...

implementation:

fn A {}
fn C {} // <<== out of order, would not compile
fn B {}

This petty strictness would allow easier orientation in the code.

2] The language would allow one to read codebase of any size linearly, like a book. You inherit someone's else project/library, and you know where to start and where to go next. You do not need to jump back and forth, again and again.

This trick makes reading of foreign code pleasure, instead of the usual pain. I was inspired how one Lisp implementation (named Wart) was organized:
https://github.com/akkartik/wart/tree/24e754b556be1ca3ee349718f660d8ca24b83d41

Basically, source files listing would look like:

010.first-file.x
020.second-file.x
050.third-file.x.

Each source file would need unique numeric prefix (and these prefixes would need to look consistent - compiler ensures it), and code from file "030" would depend only and only on code from files "001" ... "029". The compiler will ensure that this is true.

This numeric order would give firm hand to the code reader/explorer.

Even subdirectories would follow this rule

010.first-file.x
020.subdirectory.x // contains more source files
030.second-file.x.

Inside subdirectores the numbering would restart. This would allow to easily insert someone's else code:

010.first-file.x
020.subdirectory.x
      1.file1.x
      2.file2.x
030.second-file.x.
031.another-subdirectory.x
      00010.foo.x
      00020.bar.x
      00030.subdirectory.x
          3.file.x
          4.other-file.x
040.third-file.x.

The main would be in the last file. Special predefined name for this file may be considered.

3] The linear ordering above would allow to get rid of misfeature called "import" or "#include".

Every C file starts with mandatory litany of:

#include <stdlib.h>
#include "this"
#include "that"
...
#include "something-no-one-ever-heard-about"

This is madness, useless, harmful, attention killer.

In my language whatever was exported by previous files would be automatically visible in all following files, even those in subdirectories. No need for imports whatever.

Since it is assumed that the code would be developed mostly in linear fashion, name clashes would be rare. More about name clashes later.

4] Linear ordering would apply to functions inside source files too. Function A declared before function B cannot call B.

5] Since sometimes there mutual recursion between the functions, forward declaration would be allowed. However, its use would be discouraged and the compiler would sniff out useless forwards and refuse to compile them.

interface:
...
implementation:

forward fn B;

fn A()
{
  B();
}

fn B()
{
 A();
}

6] The language would allow super-easy replacement of standard library. No need for language tricks or super-advanced tooling support

If the project has subdirectory with some magic name (say "0xxx.stdlib") and this directory is placed (by its number) before other code, then this directory is the new standard library and compiler won't use the default one.

One could copy any part of the "old" stdlib there and modify it at will, remove not needed parts, or whatever.

7] Project wide configuration constants would be placed into the very first file of the project. Name of the file would be fixed (e.g. "000.project-settings.x"):

000.project-settings.x
001.stdlib.x
010.my-first-file.x
020.my-second-file.x

This way programmer is hinted to centralize project-wide settings into one, easy to spot place. No more chasing for important constants hidden somewhere deep in the source.

This configuration file would be allowed to contain only compile time constants, not an ordinary code. Compiler would make sure of this.

8] Heavy emphasize on testing. I already describer it elsewehere.

Testing machinery could do a lot of work - automatically check for memory leaks, check that test duration doesn't exceed given limit, run tests in random order, run only recently modified tests to speed the development.

Test would not require to invent any new name. This is a big help. Imagine project with thousand of tests.

9] Since having many, many tests takes lot of visual space in source file, I considered feature called "tests companion file". There's source file, and there's another file, with almost the same name, containing only tests, to offload the burden from the regular source file. This test companion file would be able to see internal parts of "parental" regular source file, as if it was included at its end.

It could look like:

040.my-file.x
040.my-file.x.tests  // this is the test companion file

The "040.my-file.x" could then look like:

...
fn a () {}

TEST()
{
  // ordinary test
}
forward TEST(name = "xyz") // this test is inside companion file
TEST()
{
 // another test

}
forward TEST(name = "xyz2") // another test inside companion file
...

Companion file "040.my-file.x.tests" would look like:

TEST(name = "xyz") // tests here are in the same order as "forwards" in regular source file
{
 ...
}
TEST(name = "xyz2", some-other-attributes) 
{
 ...
}

This would be handy feature for those obsessed with testing.

10] I planned to have compiler support for traces, for "whitebox" testing. I described it elsewhere.

11] The language would have simple module system. Source file name == module name would be the rule. No exceptions, no renaming. Source file names (and names for subdirectories) would be restricted to alphanumeric characters plus few more. Dot character would be excluded.

Names of modules would not need to be unique. If there's ambiguity in a name, the compiler would request to disambiguate it with module name. If there's still ambiguity, the compiler would request to add more parts to the the module path.

Say for:

010.dir1.x                // directory
    10.dir2.x            // ---
        001.dir3.x        // ---
            000.file.x   // finally a file

if one calls function foo from 000.file.x, then it may could to be specified as

dir3.foo()
dir2.dir3.foo()
dir1.dir2.dir3.foo()
.dir1.dir2.dir3.foo() // this is "full name path"

according to the need to resolve the name.

The shortest valid form is preferred. This would allow project to be rearranged (directories moved) with minimum of changes.

Module could be renamed by renaming the file.

12] Experimental feature I considered for module qualified names.

Typically, qualified name looks like:
library.sublibrary.func-name()

The most important part, func-name is at the end. One gets easily exhausted trying to parse through the libraries chain. Java is especially bad for this.

I thought about making it the other way:
func-name/sublibrary.library()

Here the important name-part comes first, and the part keeping compiler happy comes later.

13] To keep the language simple, I planned to offload as much as possible to the tooling (mainly to the envisioned IDE).

One biggie was constness. I came to conclusion, that const in C is just a busywork. No one modifies a value just because he can. Removing all consts would not make program crash.

An IDE could discover whether given function parameter is modified inside a function or not. It would then show it to the user. No need to do it manually

14] Another thing that could simplify the language was removing fixed size arrays, like:

int x[3];

Thinking of it, fixed sized arrays are almost never needed in real world code, apart of silly examples. One really wants to have resizable array (vector). (With fast allocator, resizable array is as fast as fixed size array on the stack.)

Removing fixed size arrays and replacing them with resizable arrays would make generic code simpler, and it would eliminate many index-out-of-range errors.

The compiler could be smart enough to internally convert resizable array into fixed array, when this is safe.

15] The code could contain examples. It would look like:

EXAMPLE(what-it-shows = "xyz")
{
  .. example code
}

Examples are different from tests, they are copy/paste friendly snippets, not tricks invoking edge cases.

Examples could come in two forms:

complete examples, that could be copied as they are and should work

incomplete examples, like:

EXAMPLE(what-it-shows= "xyz", incomplete)
{
    fn A() { ... } // the ... is there and the compiler would recognize it and ignore
    A();
}

Complete examples would be checked by the compiler for validity (but they would not be run like tests). Incomplete examples would be checked as much as feasible, e.g. for unbalanced parenthesis.

The goal was to make it easy to spot examples (big lettered EXAMPLE). They should be located just under relevant functions, but not inside test companion files.

There may be some potential to generate documentation using examples.

16] The language would not need any building system. No make, automake, CMake, qmake or other monster.

All source files would in a single directory (except for the default standard library, but this is invisible). Nothing like C's -Ipath, no code fetched online from the internet.

One would then say "compile this directory", and that's it.

17] Whole project would be compiled at once. No object files later linked together, no caches for precompiled files, no bug due to stalled files

It was hoped that compilation would be fast enough to keep this feasible.

Whole project compilation would also allow for many optimizations.

18] Compiler would output C code (in one big file), which would then be processed by C compiler. This avoids the same kind of troubles as above.

19] Generating C code allows for (relatively) easy interfacing with C. One would need to manually write function prototypes for foreign C functions. Missing language features (like const) would be ignored.

E.g.
void foo(const void* p);
would be referenced as
foreign-fn foo(void* p); // no const in the language

Some C constructs (macros, perhaps function pointers) would not be supported.

20] The language would not have global variables. There could be global constants (possibly generated during compile time), but no modifiable globals.

21] To make life easier when there are no global variables, I thought about providing "global context".

This would be a structure, with a well known name, and this structure would be automatically passed into all functions which use it.

E.g. if ctx is the magic name:

struct ctx // this global context due to its name
{
  Allocator* default-allocator;
  Logger* logger;
   int x;
}

fn foo() // pointer to ctx  passed behind the scenes
{
  ctx.logger("foo() called"); // global context used
}

void main()
{
  struct ctx ctx; // this declares the global context
  ctx.logger = ... // filling it

  foo();  // global context gets passed by default, as &ctx
}

Tests would declare context of their own.

Some parts of global context would be mandatory (e.g. the default-allocator). Libraries would also need some way to use non-mandatory but commonly expected parts of global context. This is described next.

22] "If it compiles, use it!"

Code may try something and hope for the best:


fn foo() 
{
  // If global context structure contains "logger" member, use it. 
  // If it is not there, ignore the code after ???
  ??? ctx.logger("foo() called"); 

  // the same with different syntax
  ??? [[
    ctx.logger("foo() called"); 
  ]] else [[ // optional else clause
    ... // do some alternative
  ]]
  

  // Here the value ctx.x is made mandatory. If it is not present in the context, 
  // project won't compile
  ctx.x = 1;
}

This would allow 3rd party libraries to use expected functionality from the context, but if this functionality was not needed, it use is automatically avoided.

I hoped that global context and automatic conditional compilation would make reusing someone's else library easier.

23] Sometimes I would want to use 3rd party library, but only very, very small part of it. I do not want unwanted code from the library to interfere with the rest of project, or to be used by mistake.

Here's the idea:

copy the 3rd party library into a subdirectory with certain name
make source file with the same name as subdirectory
into this source file place functions which make the desired interface. These functions do have access to the 3rd party library and invoke it as needed
all followup source code has now access to this interface source file (as usual), but not to the 3rd party library (this is the unusual part). Useful functionality was exposed cleanly, but nothing else.

Graphically it would look like:

000.project-settings.x

010.foreign-library.x.lib   // <<== this library "sees" constants from 000.project-settings.x
      00010.file1.x
      00020.file2.x
      ....
      0670.file67.x // lot of code I do not really want

// Now I define limited API for the foreign library. 
// Here and only here I have full access to it
010.foreign-library.x 

// Now I can use exports from 010.foreign-library.x, 
// but *nothing* directly from that foreign library
020.my-file.x

So if foreign library exposed functions from A1 to A999, and I am interested only in A3, then the source file 010.foreign-library.x would look like:

interface: 
fn my_A3();
implementation:
fn my_A3()
{
  A3/foreign-library();
  // or
  foreign-library.A3();
}

Nowhere else I am allowed to call into foreign-library, and all I expose comes from this helper source file. Nothing from foreign-library leaks into the rest of the project (as would normally happen for ordinary code in subdirectories).

This feature was hoped to make it possible to reuse code without fear.

24] The language would not offer one global heap allocator like C does.

Instead, there would be common API, and several implementations (traditional block based allocators; allocators which just increments a pointer (arena allocators) and free() is no-op; their combinations).

Having own allocators allows for:

easy leak detection (with each test and at the end of application run)
checking for overwrites
having faster thread unsafe allocators (which makes sure there's no misuse)
checking for freeing wrong pointer, for double freeing, etc.
collecting statistics for later fine-tuning
allocators could be limited how much memory they provide
some allocators may allow freeing all allocated memory at once, instead of manual freeing (free would be no-op)

Defensive allocators are really good for error catching. Arena allocators are incredibly fast.

25] assert would not be just an ordinary function.

It would be able to show lot of information:
assert(x < y, "x = %d, y = %d, z= %d", x, y, z);

The compiler will try to understand meaning of asserted expression. In some cases it should be able to statically check for the code using the information gleaned from assert. E.g. non-nullness:

// now compiler knows the parameter cannot be null, and enforces it in callers
fn foo(void* p)
{
  assert(p != null);
}

When the compiler is unable to statically enforce asserted restriction (it gets too complicated fast), the check would stay there for run time, as expected.

fn foo(double x, y, z )
{
  assert(arctg(x) == sin(y) + cos(z));  // this would be too hard to verify at compile time
}

26] The language would provide generics, but in simple way, without the usual ceremony. Asserts would be used, instead of complex type system.

fn foo(type x) // generic function
{
  assert(is_integer(x) or (is_float(x)); // is_integer/is_float are magic functions from stdlib
  ...
}
fn bar(type* y)
{
  // Checks that "y" type has member function foo() 
  // and that it has bar() function which returns int.
  //
  // If it cannot compile, the overload is rejected.
  //
  // ??? is "does it compile", it was introduced earlier. 
  // In this context it acts as compile time bool function.
  assert(???[[
    y.foo();
    _ : int = y.bar()
  ]]);
}

Using asserts allow to make very complex requirements for generics, without the need to design complex types, concepts or whatever. Just show the compiler what you want to do with it.

27] Tiny feature to improve code self-documentatation: if+/if-.

if+ x > 0 {   // this says it is likely that the condition is true
  ...
}
if- y == z { // this says that the condition is rather unlikely
  ...
}

This featurette allows one to notice possible trouble during debugging: if the code goes the "wrong" path, it may signal a problem. It serves as one character long documentation hint.

It may also help to generate a little bit more efficient code. GCC and clang support feature called __builtin_expect (https://stackoverflow.com/questions/7346929/what-is-the-advantage-of-gccs-builtin-expect-in-if-else-statements).

28] Errors. I had covered them elsewhere. The emphasize was on simplicity, not versatility. Complicated errors would need more effort.

29] I planned to support code running at compile time. It could be used e.g. to initialize global constants.

Syntax may look e.g:

const double some_table[100];
comptime // not a function, just a snippet invoked as the source is parsed
{
  for i in 0. .. 99
   some_table[i] = sin(cos(i));
}

...

void foo()
{
  // initialization value calculated at compile time
  int x = comptime { 
              .. // complicated calculation done in compile time
              42;
             }
   ...
}

I do not think compile time code needs to be as powerful as e.g. in Jai language.

30] One of major goals of the language was to reduce number of names (symbols). The less names one needs to invent, the better. This also pushes one to use shorter names, instead of the enforced eloquency of "isDataFlagInSubscriptionTableFullyElaborated".

One way to reduce number of names is to allow function overloading. Some people are against function overloading, I never understood why. They seem to think that "FunctionWhichDoesThisAndThatAndCertainlyHasUniqueName" is great for understanding.

As long as the compiler can safely resolve which overload to use, everything is permitted.

Overload would be resolved:

by number of parameters
by type of parameters (but there would be no automatic type coercion)
by return type (experimental idea)

by using named parameters

fn foo( x_position : int) { ... }
fn foo( y_position : int) { ... }

foo(x_position = 10); // no ambiguity here

by explicit module specification

Advanced IDE would be able to show which overload is used, and what are the alternatives.

Tests do not require unique names, or any names at all. Imagine having 10,000 tests ...

31] To keep names simple, I would allow some non aplha-numeric characters to be use in names: - a separator (more readable than underscore), ? at the end for functions returning boolean, # at the end for function returning some kind of count. Perhaps few more.

Some rules on characters use may be enforced by the compiler.

Expressions using these characters would need to employ spaces, to make a distinction:

this-is-name
this - is_subtraction
-1 // number
-x // negate value of x
not_allowed-
x - y - z // expression, not name

32] On the other hand, I woudn't allow UTF8 in code at all. Too dangerous to make a mischievous overload. Unicode has some specification for "safe" characters (http://unicode.org/reports/tr31/), but this is way too complicated.

UTF8 in strings may or may not be allowed. I wasn't sure.

33] Since the code is organized linearly, it should be possible to insert new main function into any source file, even in the middle of a project, and expect it to compile. The rest of the codebase would be ignored. (Forwards would need to be resolved, but this is only nuisance, not showstopper.)

This would allow one to explore foreign codebase, or library, step by step, without the need to set up a new project.

By default main in the last file is the used one, but command line switch could select a different main.

Theoretically, this feature may also allow to generate more than one application from single codebase (e.g. command line version and GUI version).

34] Named parameters would be allowed. (They were mentioned before, in overloading section.)

They could be also used for this trick:

// complicated drawing
draw_line(x = 10, y = 20, thickness = 1, color = red);
draw_line(x = 20, y = 20, thickness = 2, color = red);
draw_line(x = 30, y = 20, thickness = 2, color = blue);
draw_line(x = 40, y = 20, thickness = 4, color = red);
draw_line(x = 20, y = 30, thickness = 2, color = green);

looks clumsy.

I would love to have this:

params = [[ // this declares table full of parameters
  x      y     thickness    color
  --    --    -----------   ------
  10    20      1           red
  20    20      2           red
  30    20      2           blue
  40    40      4           red
  20    20      2           green
]]
draw_line(params); // this would do the same as above

Smart compiler would rearrange tabular form into sequence of calls.

Advanced IDE would make creating the table easier.

35] I planned to make compiler smart enough to recognize traditional tricks used in typography to reduce repetitive typing.

E.g.

some_struct.x = 100;
some_struct.y = 200;
some_struct.z = 300;

could be written as:

// should be aligned visually
some_struct.x = 100;
           .y = 200;
           .z = 300;

The compiler would notice strange uncompilable thing here, would try to guess if this is a shorthand, if this makes it working, it would apply it quietly.

To me this old trick feels more natural than to invent strange and clumsy compiler constructs (with).

36] My language would have very simple form of object oriented support. Some people see OOP as bad, but there are dangerous parts (inheritace) and harmless parts (information hiding).

There would be two types of objects:

Simple objects without any polymorphism. No inheritace. Members always private, no automatic getters/setters. There would be constructor, destructor, perhaps copy constructor and assignement operator.
```
class point
{
  int x, y; // member data has to be defined first
  void _init() {} // private helper (specified by _)
  point(x, y, int) { ... }
  ~point();
  void foo() { ... }
  void _bar() {} // private helper (specified by _)
   ...
}
```
This type of object is IMO easy to understand and completely harmless.

Polymorphic objects. There would be abstract class and one (no more!) level of inheritance. Only pointers to abstract class would be allowed to be declared and passed around. Pointers to subclass type would not exists at all. Every object would need to be allocated and accessed via pointer.

abstract class abstract_point
{
  // no data members allowed, no constructors/destructors

  // only public polymorphic function declarations allowed here
  void foo(); 
  void bar();
  ...
}

class cartesian_point : abstract_point
{
  int x, y; // data members
 .. constructor, destructor (always virtual)
 // implementations of all polymorphic functions, in the same order as in parent
}
  
class polar_point : abstract_point
{
  int rho, phi; // data members
 .. constructor, destructor (always virtual)
 // implementations of all polymorphic functions, in the same order as in parent
}

Single level of inheritance prevents one to create monstrous hierarchies., while still providing polymorphism. Potentially, polymorphic objects could replace traditional functions pointers, making the language more simple and robust (functions pointers make deductions about the code hard).

Since the whole program is compiled at once, the compiler knows all subclasses, and could support safe and complete switch on them, instead of forcing the developer to add virtual function:

fn foo(abstract_point* pt)
{
  switch (pt) {
   case cartesian_point: 
     ... do someting
   case polar_point:
    ... do something else
  }
}

The compiler would make sure there's no class omitted in the switch. Advantage of the switch is, that related code is place in one place, not spread into many files.

37] Structures padding (and alignement) would be explicit, unlike in C. No more guessing what is going on inside.

struct foo
{
  byte b;
  int x;   // <<=== the compiler would refuse this, padding is missing
}

struct foo
{
  byte b;
  padding(3); // 3 bytes of padding, must be explicitly written
  int x;  
}

Bit padding could be implemented in the same way:

struct foo
{
  bit[2] x;
  bit[2] y;
  padding(bit[4]);
   byte z;
}

The compiler would check against user's mistake - wrong padding, excessive padding.

If "wrong" placement is needed:

struct foo
{
  byte b;
  no-padding; // here I really mean it
  int x;  
}

38] Other thing I wished from the language was reduction of indentation. Code sitting on the left side reads better.

There are few tricks that could be used:

  for (... ) {
      for (...) {
          for (...) {
              if (...) { 
                // finally here's something important
              }
          }
      }
  }

could be perhaps written as:

  for (first-loop | second-loop | third-loop) {
     if (...) { 
      // the important part
     }
  }

Classes could be perhaps written like:

class x
[[ //<<== different type of braces

// look, no indentation 
fn foo() 
{
...
}
fn bar() 
{
 ...
}

]] // <<== end of class specification

Some other tricks could be invented. The intention is to improve readability by moving the code left as much as possible.

39] I considered disabling pointer arithmetic by default. This would eliminate a lot of bugs. If pointer arithmetic is needed anyway, there would be some special form for it, clumsier to use by intention.

40] I wanted to have explicit hints what to inline and what not:

// definitions
inline fn foo() {} // Must be inlined. If impossible -> error
no-inline fn bar() {} // never inlined

// when called
x = no-inline foo(); // not inlined, stronger hint
y = inline bar(); // must inline, stronger hint

fn baz()
{
  // the annonated part of the function would be always inlined, 
  // the remaining part of the function woudn't be inlined
  //
  // If not applicable -> error
  //
  inline [[
    if (something-very-common) {
      return;
     }
  ]]
  ... // very complicated code here
}

41] To make the language simpler, all structs and objects could be passed into function only by pointer parameters. No slicing or copying.

Structures could be returned, and it would get RVO optimized.

42] Hello Wold examples and single file utilities could be written in simpler way:

// hello-world.x (no numeric prefix)
void main()
{
  echo("Hello World\n");
}
// end of the file

Usual restriction and requirements wouldn't apply on single file projects:

no need for structured file names like 007.name.x
no need to have the otherwise mandatory 000.project-settings.x
no interface:/implementation: structures inside the file
default standard library always used

However, there were problems I didn't solved fully:

1] How to implement paralelism. I certainly didn't want anything overcomplicated like Pony.

One thing I planned were mutexes that self-check for deadlocks, in debug mode.

2] Debugging. I didn't find easy way to have reasonable debugger for the generated C code.

I considered, that for debug mode, I would use bytecode interpreter, instead of the C generator. I do have some idea how to make debugger for interpreter.

3] I postponed selecting the name for the language. I wanted something googleable.

4] Dynamic libraries are problem. They break many assumption about the code, the interfere with the "everything is compiled at once" principle. Either I would not support them, or would restrict their use. For example, it shouldn't be possible to define polymorphic subclass in dynamic library.

5] Function pointers. They have the same problems as above. I though that, perhaps, they could be removed from the language and replaced by (less free to do anything) polymorphic objects.

If someone managed to read it all, have my congratulation. I tried to describe novelty features. The rest would be mostly the same as C, with minor improvements and simplifications here or there.

Questions welcomed.

I guesstimated, that it could take up to decade to implement it.

dsnippet · 2019-03-16T11:37:30Z

Hey, your code generator does not even have a block for D and yet on the compilation speed benchmark page you list D with a comment "segfaults after 6 minutes".

What is the credibility of your benchmark?

dsnippet · 2019-03-16T11:42:41Z

I am referring to the benchmark mentioned in hacker news. https://news.ycombinator.com/item?id=19405036

medvednikov · 2019-03-16T11:44:08Z

Hi @dsnippet

No need to be so agressive :) I simply forgot to push the code.

Done now.

Go also segfaults. Java refuses to compile it. It's all because there's just too much code in one function.

I'll improve the test soon.

tjpalmer · 2019-03-16T14:50:08Z

@medvednikov Your language description hits the most important points. I have different stylistic opinions in some cases, but eh. If you can deliver what you've said under a liberal open source license, that's what matters. Most importantly, I recommend finalizing some kind of 1.0 that people can rely on as soon as possible, even if it doesn't have every feature you want. If you get bogged down in everyone's suggestions and all the possibilities, that will prevent people from being able to use V soon as a stable product.

jkaye2012 · 2019-03-16T14:54:53Z

I would not rush a 1.0. That's a great way to lock yourself in to backwards compatibility issues for a long time.

…

On Sat, Mar 16, 2019, 9:50 AM Tom Palmer ***@***.***> wrote: @medvednikov <https://github.com/medvednikov> Your language description hits the most important points. I have different stylistic opinions in some cases, but eh. If you can deliver what you've said under a liberal open source license, that's what matters. Most importantly, I recommend finalizing some kind of 1.0 that people can rely on as soon as possible, even if it doesn't have every feature you want. If you get bogged down in everyone's suggestions and all the possibilities, that will prevent people from being able to use V soon as a stable product. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5V_NQrMm5-_XsEBBsXAOhYlCnTFdoIks5vXQSigaJpZM4a-WGd> .

tjpalmer · 2019-03-16T17:37:59Z

And Jai will be great once it's done, too ... Someday, maybe.

damianesteban · 2019-03-19T20:18:42Z

So far I think it looks great. The syntax is Go-ish, but seems much more interesting to write than Go :). Great job.

On a side note, Volt is an awesome project.

PavelVozenilek · 2019-04-05T22:02:55Z

Very small feature: basic types may provide minimum and maximum constants in form:

i8.max (== 127)
i8.min (== -128)
u64.max (== 4 billion)

rune.max would be the Unicode upper limit.

The dot syntax is just the simplest one.

proyb6 · 2019-05-08T19:50:50Z

Having Gnu MultiPrecision Library.out-of-box in V syntax when we will have to deal with a huge number is extreme useful.

PavelVozenilek · 2019-05-17T09:12:57Z

Writing it here, as I do not have twitter account.

There a poll about forcing name style for constants. While this would be desirable most of the time, there are situations standing against mandatory form. SCADA systems, for example. You have thousands of data points, and they all have been assigned name by an outside authority. These names have meaningful internal structure. You are not free to change them or invent your own substitution.

chanbakjsd · 2020-01-14T14:43:14Z

This issue has been closed due to the inactivity.
Please open a new issue instead if you have something to discuss.

medvednikov changed the title ~~Just published the first V example to show you some features of the language~~ Just published the first V example to show you some features of the language. Very interested in your input. Feb 19, 2019

PavelVozenilek mentioned this issue Mar 11, 2019

Support for testing #9

Closed

malexdev mentioned this issue Mar 15, 2019

Underscore separators? #19

Closed

medvednikov mentioned this issue Apr 1, 2019

Can I write require member? #52

Closed

alfonsodg mentioned this issue Jun 23, 2019

Core dump after bootstrap #450

Closed

shaoxie1986 mentioned this issue Jun 23, 2019

./vc --help segfaults #438

Closed

chanbakjsd added the announcement label Jun 25, 2019

fantassin mentioned this issue Sep 26, 2019

Add support for Solaris #2093

Closed

elimisteve mentioned this issue Oct 26, 2019

Empty value vs Option/Result vs panic #2512

Closed

adlesh mentioned this issue Nov 19, 2019

Implement low-level locks eg: for bare-metal/freestanding #2802

Closed

sha0coder mentioned this issue Dec 4, 2019

SSL handshake segfaults if BIO_do_connnect don't connect #2976

Closed

chanbakjsd closed this as completed Jan 14, 2020

krischerven added a commit to krischerven/v that referenced this issue Apr 12, 2020

CI fix attempt vlang#3

ba18edc

kalapalo mentioned this issue Jul 18, 2020

cgen: fix assignment for sumtypes with pointers #6 #5868

Merged

kalapalo mentioned this issue Sep 21, 2020

Fix sumtype primitive variants 2 #6342

Closed

spaceface777 pushed a commit to spaceface777/v that referenced this issue Nov 11, 2020

termios: add C.IXON to c_iflag in raw input mode (vlang#3)

8f155f3

spaceface777 pushed a commit to spaceface777/v that referenced this issue May 3, 2022

Add /usr/lib64 to tcc's --libpaths= configure option too. (vlang#3)

6b80fac

madelinehebert mentioned this issue Sep 16, 2024

Compilation fails under Illumos / OmniOS r151050 #22236

Open

Just published the first V example to show you some features of the language. Very interested in your input. #3

Just published the first V example to show you some features of the language. Very interested in your input. #3

Comments

medvednikov commented Feb 15, 2019 • edited Loading

ducdetronquito commented Feb 19, 2019 • edited Loading

xorhash commented Feb 21, 2019

medvednikov commented Feb 21, 2019 • edited Loading

medvednikov commented Feb 21, 2019

medvednikov commented Feb 21, 2019 • edited Loading

burlesona commented Feb 21, 2019

burlesona commented Feb 21, 2019

emidoots commented Feb 21, 2019

medvednikov commented Feb 21, 2019 • edited Loading

burlesona commented Feb 21, 2019

emidoots commented Feb 21, 2019 • edited Loading

oliwer commented Feb 21, 2019

medvednikov commented Feb 21, 2019 • edited Loading

emidoots commented Feb 21, 2019

boyter commented Feb 22, 2019

rrjanbiah commented Feb 22, 2019

medvednikov commented Feb 22, 2019

International commented Feb 22, 2019

medvednikov commented Feb 22, 2019 • edited Loading

medvednikov commented Feb 22, 2019

haltcase commented Feb 22, 2019

medvednikov commented Feb 23, 2019 • edited Loading

Francesco149 commented Feb 23, 2019

medvednikov commented Feb 23, 2019

dsnippet commented Feb 23, 2019 • edited Loading

dsnippet commented Feb 23, 2019

medvednikov commented Feb 23, 2019

awesomekyle commented Feb 23, 2019

medvednikov commented Feb 23, 2019

jkaye2012 commented Mar 10, 2019

PavelVozenilek commented Mar 12, 2019

dsnippet commented Mar 16, 2019

dsnippet commented Mar 16, 2019

medvednikov commented Mar 16, 2019 • edited Loading

tjpalmer commented Mar 16, 2019

jkaye2012 commented Mar 16, 2019 via email

tjpalmer commented Mar 16, 2019

damianesteban commented Mar 19, 2019

PavelVozenilek commented Apr 5, 2019

proyb6 commented May 8, 2019

PavelVozenilek commented May 17, 2019

chanbakjsd commented Jan 14, 2020

medvednikov commented Feb 15, 2019 •

edited

Loading

ducdetronquito commented Feb 19, 2019 •

edited

Loading

medvednikov commented Feb 21, 2019 •

edited

Loading

medvednikov commented Feb 21, 2019 •

edited

Loading

medvednikov commented Feb 21, 2019 •

edited

Loading

emidoots commented Feb 21, 2019 •

edited

Loading

medvednikov commented Feb 21, 2019 •

edited

Loading

medvednikov commented Feb 22, 2019 •

edited

Loading

medvednikov commented Feb 23, 2019 •

edited

Loading

dsnippet commented Feb 23, 2019 •

edited

Loading

medvednikov commented Mar 16, 2019 •

edited

Loading