profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Martinsos/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Martin Šošić Martinsos wasp-lang.dev Croatia martinsosic.com Creator of Wasp and Edlib. Enthusiastic about Linux, Emacs, Clean code, functional programming, algorithms, startups, customer development, building a product.

Martinsos/edlib 338

Lightweight, super fast C/C++ (& Python) library for sequence alignment using edit (Levenshtein) distance.

Martinsos/arduino-lib-hc-sr04 48

Arduino library for HC-SR04 ultrasonic distance sensor.

Martinsos/dotfiles 5

Contains my dotfiles.

Martinsos/datepicker-position 2

Enables other alignments of bootstrap datepicker except to the left

Martinsos/lox-haskell 2

Implementation of Lox language (from "Crafting Interpreters" book) in Haskell

Martinsos/angular-charts 0

Me playing with custom made charts

issue commentwasp-lang/wasp

[Analyzer] Support nameless declarations

@craigmc08 makes sense I forgot about that! That is a good analysis -> let's keep it at this for now and we can revisit this in the future, this is certainly not urgent right now. I think it will make sense at some point to have these nameless declarations, but as you said for now we can either just make them part of the app, and then we can figure it out as we go.

Martinsos

comment created time in a day

issue commentwasp-lang/wasp

[Analyzer] Remember name of referenced declaration

Well imagine having two pages with exactly the same content but different names -> somewhat silly, but it is something we should allow -> in that case, we do want to be able to distinguish them.

And in Generator right now -> so generator will create a React component for the HomePage and when choosing a name for that component it will actually name it HomePage..., and then we have defaultPage set to HomePage as in example above, it will generate a route that points to that page -> but for that it will need to know which React component to import, and that is HomePage..., so the name is important.

There are also some other situations where this could be important.

If we assume names are important -> does Ref sounds reasonable to you, or would you do it in some other way? What do you dislike about Ref?

Martinsos

comment created time in a day

issue openedwasp-lang/wasp

[Analyzer] Make Analyzer.Parser and Analyzer.TypeChecker use the same AST

Right now, each of them has their own AST, but those AST's are actually extremely similar -> they have the same structure, it is just that TypeChecker AST is enriched with additional information.

Therefore, it might make sense to actually reimplement these two AST's as one AST that is parametrized by "context", which is really an additional information to be attached to each node -> that way we avoid duplication and ensure that two AST's won't get desynced. On the other hand, this limits the AST as it has to have the same structure for both Parser and TypeChecker -> as long as that is true, we are good, but if that stops being true and we need more flexibility, we will not be able to use it any more.

So the question is: are we fairly sure that these AST's will always have the same structure? If so, let's do this refactoring. If not, let's leave it as it is and we can close this issue.

created time in a day

issue openedwasp-lang/wasp

[Analyzer] Support splitting Wasp source code into multiple files (Wasp modules)

This has been discussed and solution has been proposed by @craigmc08 in the https://github.com/wasp-lang/wasp/tree/master/waspc/docs/wasplang, so we should take a look there. Might be worth talking again with @craigmc08 once we start working on this.

created time in a day

issue openedwasp-lang/wasp

[Analyzer] Improve type error reporting

While we do report type errors right now in Analyzer, we report only first error we encounter and error messages are very raw + contain no context information (e.g. the position in the source code). We should improve this!

  1. Report multiple errors (by doing some kind of error recovery, e.g. putting a boundary at the lvl of statement / declaration).
  2. Report position of error in source code.
  3. Make user-readable messages for all errors, especially for unification/weaken errors since they are not that understandable.

TODO for this in TypeError.hs

created time in a day

issue openedwasp-lang/wasp

[Analyzer] Add support for quoters in type definitions

Currently, quoters ({=json json=}, {=psl psl=}, ...) are hardcoded in the language.

But, since they all follow the same philosophy, they could be abstracted away and then specific instances of quoters could be injected with type definitions, same as we are doing now for Declaration types and Enum types.

Quoters might be a bit different because we might also want Parser to care about them (or not and instead we might delegate that to some later step in Analyzer, not sure yet).

There is TODO about this in Analyzer.TypeChecker.Internal. Another in Analyzer.TypeChecker.AST. One more in Analyzer.TypeDefinitions.Internal.

created time in 2 days

issue openedwasp-lang/wasp

[Analyzer] Adapt (to) new syntax

New syntax is a bit different from older syntax -> for example, we don't have special syntax for route any more, now it is just a normal declaration.

We should either extend Analyzer to support the syntax as it was before, which means we add some kind of "sugar" that allows defining routes in that nicer way, or we should update the docs / examples to use the new syntax.

created time in 2 days

issue openedwasp-lang/wasp

[Analyzer] Enable referencing of declarations that are below in the source code

Right now, in Analyzer, we can't do

route { path: "/", page: HomePage }

page HomePage { content: "Test" }

because HomePage is first referenced and then declared!

We want to support this.

There is a TODO for this in Analyzer.Evaluator and it is a good place to start. @craigmc08 had some ideas on how to handle this, and he might have also mentioned something in the LaTeX document he wrote (https://github.com/wasp-lang/wasp/tree/master/waspc/docs/wasplang).

If we do Ref approach from https://github.com/wasp-lang/wasp/issues/308, it might make solving this problem much easier -> anyway, we should take it into consideration while doing this.

created time in 2 days

issue openedwasp-lang/wasp

[Analyzer] Use Wasp.hs types in Analyzer

We will need to modify those types, which means old code will stop working, and we don't want that yet.

So what we should probably do is create new Wasp.hs, we could name it Wasp.AST.hs since that is probably also a better name, and then implement new types there to be used in Analyzer, and they will be very similar to those in Wasp.hs.

But how do we make Generator work with both Wasp.hs and Wasp.AST.hs then? We could write a piece of code that transforms Wasp.AST.hs into Wasp.hs! It should be short. And then once we decide to switch to Analyzer completely, we will modify Generator so it works with Wasp.AST.hs and remove Waps.hs and code that transforms Wasp.AST.hs into Wasp.hs.

created time in 2 days

issue openedwasp-lang/wasp

[Analyzer] Support nameless declarations

Some declarations, like route or dependencies, don't need a name, there is no purpose in them being named.

Therefore, we should allow them being nameless:

route { path: "/", page: HomePage }

dependencies {=json
  mylib: "1.0.0"
json=}

Right now, this is not supported!

What do we need to support it?

  1. We need to modify Analyzer.Parser so it allows for declarations without a name (or maybe it already allows that? I don't think so).
  2. We need to modify Analyzer.Evaluator.Decl so it doesn't always expect a name to be associated with a declaration
  3. Something else? But I think things above are main places and the rest of the changes will stem from there.

created time in 2 days

issue openedwasp-lang/wasp

[Analyzer] Remember name of referenced declaration

If we have following Haskell types

App { defaultPage :: Page }
Page { content :: String }

that are both instances of IsDeclType, and we have following Wasp source code as input to Analyzer:

page HomePage { content: "Hi" }
app MyApp { defaultPage: HomePage } 

then the output of Analyzer will be:

[ ("HomePage", Decl (Page { content = "Hi"})), ("MyApp", Decl (App { defaultPage = Page { content = "Hi"}}))

Decl is actually a heterogenous type so that is why we can have a list like this, which I described in a bit of pseudocodish manner above.

As is visible in the output of Analyzer, there is no way for us to figure out that defaultPage from App is the one named "HomePage"! And this is a problem, because Generator cares about that name, it considers it to be the very name of the page and needs it to be able to correctly work with it. But, it can't because it doesn't know the name of the page that defaultPage is describing.

In the old Wasp AST this is solved by all references being just names (Strings), so defaultPage would be just a String that is a name of the page. But that is in itself pretty unelegant and unsafe approach.

So what could be the solution to this? Some ideas:

  1. Package the declaration name together with the Page somehow -> maybe say that if Page has name field, then we will always set it to the declaration name (while defining the IsDeclType with TH), or smth like that?
  2. Introduce Ref type, as permanent construct of Wasp AST, and instead of having App { defaultPage :: Page }, we would have App { defaultPage :: Ref Page }, and Ref contains the name and is properly handed by the Analyzer. Ref is really type Ref a = (String, a) in its core, or maybe even just type Ref a = String, not sure yet.

It is up to us to decide how we want this to work, what makes the most sense, what does the "name of the declaration" mean in Wasp and how it should behave. Maybe going with Ref would also easily enable referencing declarations that have not yet been declared, which is currently not supported?

created time in 2 days

issue commentwasp-lang/wasp

Implement new version of Wasp compiler (analyzer)

So, right now we have MVP done, with all parts in and working: Parser, TypeChecker, Evaluator. However, there are features missing, and currently our Analyzer is using mock types, not the ones from Wasp.hs.

Here goes the plan to bring Analyzer to the stage where it can replace current Parser:

  1. Ensure that each declaration is packed with its name, if it has one. Maybe this is already ok but I am not sure, we should check and make it work if it's not. What does this mean? If we have app MyApp ... that has property defaultPage of type page and is set to HomePage where we have page HomePage ..., then when generator receives the AST to work with, it will need to know the name of the declaration that defaultPage is pointing to. And I am not sure if that is currently part of AST in this case or not.
  2. Ensure that nameless declarations, like dependencies { ... } are supported.
  3. Use types from Wasp.hs in Analyzer! Maybe best to create a new module, Wasp.AST, and go from there? Update StdTypeDefinitions.hs and Delete Evaluator.Types . As a result, Generator might need updating also, to work with these new types? But then it will stop working with old types. A bit tricky. Maybe we can implement adapter from new WaspAST to existing Wasp, so that Generator is reused?

This should be enough to get Analyzer working end to end!

Next, we want to get it to the same level as current implementation is:

  1. Enable referencing of declarations described below the current location in the source code. Start from Evaluator.hs.
  2. New syntax is a bit different from older syntax -> for example, we don't have special syntax for route any more. We should either add that syntax to compiler, or we should update the docs / examples.
  3. Other -> I am sure we missed some stuff, but that will be easier to identify once we give it a try.
  4. Remove old Parser and let Analyzer do all the work.

This is it, Analyzer is in action and is being used!

Finally, there are further improvements to be made:

  1. Add quoters to type definitions. -> refactoring There is TODO in Analyzer.TypeChecker.Internal. Another in Analyzer.TypeChecker.AST. One more in Analyzer.TypeDefinitions.Internal.
  2. Improve type error reporting 9.1. Report multiple errors 9.2. Report position 9.3. Make user-readable messages for all errors, especially for unification/weaken errors since they are not that understandable. TODO for this in TypeError.hs
  3. Advanced: support for splitting Wasp into multiple files.
  4. Share same AST between Parser and TypeChecker? This is a refactoring / optimization and can be done later
Martinsos

comment created time in 2 days

startedkowainik/stan

started time in 3 days

delete branch wasp-lang/wasp

delete branch : analyzer-evaluator

delete time in 3 days

push eventwasp-lang/wasp

craigmc08

commit sha d043548eccf7b29c98240d3a34bbf1f1795edd48

Get evaluation working a bit Code is probably not great, but passing tests for generating haskell data structures exist! Still have to hand write IsDeclType and IsEnumType instances, but it's cool

view details

craigmc08

commit sha 4120bc53dc4ef8c8d3b53d1d6fa166ee1511f9d1

Add TH generation for IsDeclType, IsEnumType instances

view details

craigmc08

commit sha 865a5196aab0efc3f3b6e95271afc0a012b9d9d5

Refactor evaluator TH code and add more comments

view details

craigmc08

commit sha 5f3f8454160b9a465d539c006486e0f48e9b128d

More cleanup in TH

view details

craigmc08

commit sha 2507a71abe0cbadc55b7d7125e6b19c915a0cdba

Add evaluation for import, json, psl

view details

craigmc08

commit sha 923a9ad35a967850f5ec868ce239839c55f1a3ca

Refactoring

view details

craigmc08

commit sha b294e42889e1db58fab7f3920bb4b8462d951724

Refactor EvaluationError type

view details

craigmc08

commit sha 9686eaf4dc05ef6c1a962d634d1b7be3682f9001

Add test for Analyzer module

view details

craigmc08

commit sha 43450647c7ad74a9cf7e00f23f66a1a2c6f13837

Fix some comments

view details

Craig McIlwrath

commit sha d37cfed9f9bcb2eab781768d88a3d0d76a004631

Apply suggestions from code review Co-authored-by: Martin Šošić <Martinsos@users.noreply.github.com>

view details

craigmc08

commit sha c99e9a90507d6a91b0747d77ea7f898331b0dc24

Suggestions from code review

view details

Martin Šošić

commit sha d283aabdaf3e23f6a372c60f9dd70d5e5d58d25c

Added some general Analyzer docs. (#302)

view details

Martin Šošić

commit sha 9455697c51e1ab5821695ae77bd382d4467f0b16

Added IsDeclType constraint to Decl, hidden its internal representation. (#303)

view details

Martin Šošić

commit sha 7a32aa38c40af505c4990ef28e384faf11705832

IsDeclType and IsEnumType now have toDeclType and toEnumType functions. (#304)

view details

Martin Sosic

commit sha 147d1d646683679fa7283bf217392cd5540b731e

Separated EvalCtx from evaluation input in Evaluator.Combinators and removed duplication.

view details

Martin Sosic

commit sha cb50008b98fb91f53a59216566a00a0ce0331e1e

fix

view details

Martin Sosic

commit sha 5a1ba5017a99070d50d393685f2c70cd43a7f0cb

fix

view details

Martin Sosic

commit sha 5c19d42ed10b158b1c766b7b6cd5aaa27ed6933d

fix

view details

Martin Sosic

commit sha 123765c494753e2b3395d1864c48f75f30b84201

fix

view details

Martin Sosic

commit sha dd96f724e1ed0f01f0557bc83d9e60c82d9f4b4f

Refactored Evaluator.Combinators into more structured code.

view details

push time in 3 days

PR merged wasp-lang/wasp

feat: Implement evaluator for new type checker

Description

Implements the evaluator phase for the new analyzer. The evaluator works by running the TypeDefinitions.declTypeFromAst function for each declaration in the type-checked AST. Additionally, Template Haskell functions (in Analyzer.Evaluator.TH) were created to automatically generate DeclType and EnumType instances from Haskell type names.

Type of change

  • [ ] Code cleanup
  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [X] New feature (non-breaking change which adds functionality)
  • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • [ ] This change requires a documentation update
+1962 -153

3 comments

34 changed files

craigmc08

pr closed time in 3 days

PullRequestReviewEvent

push eventwasp-lang/wasp

Martin Sosic

commit sha a25f8fc809d83be584cb779b387ed957b377423a

Renamed Evaluation.Core to Evaluation.Internal.

view details

push time in 3 days

issue openedAlexander-Miller/treemacs

Feature request: visually indicate where the end of the open directory is

Right now, when file tree is relatively complex, I find it hard to figure out where the end of the directory contents is.

How hard would it be to add an option to show a vertical line (or some other kind of visual indication, maybe alternating background color) extending from each open directory all the way to the last of its children?

So for example, right now for me treemacs looks like this:

image

But with the feature I described above, it could look like this (I sketched two different visualization ideas, and I like the one to the right better, it is visually easier to follow):

treemacs-suggestion

created time in 3 days

issue openedAlexander-Miller/treemacs

Feature request: option to not always list files after directories

Thanks for this great package!

Right now, directories are always shown before the files on the same level, and modifying treemacs-sorting variable does not help with this since it explicitly says that "Files will still always be shown after directories".'

Is there any way to tell treemacs to mix files and dirs when sorting, instead of pushing files to the end?

I am working with Haskell projects lately, and there you often have MyModule.hs file and MyModule/ dir, and it makes a lot of sense to see them next to each other in the tree since they make a single "subtree" where .hs file is a kind of a value of the top node, to put it that way. So ideally, if we have

Foo.hs
Foo/Bar.hs
Duh.hs

instead of order being

Foo/
  Bar.hs
Duh.hs
Foo.hs

I would like it to be

Foo.hs
Foo/
  Bar.hs
Duh.hs

Is there a chance we could add option to treemacs-sorting that would support this? Or maybe it would be a separate option?

Thanks!

created time in 3 days

startedAlexander-Miller/treemacs

started time in 3 days

push eventwasp-lang/wasp

Martin Sosic

commit sha 84f32b0e67566a34179a462957b1416b7513dc2d

fixed ormolu

view details

push time in 4 days

Pull request review commentwasp-lang/wasp

feat: Implement evaluator for new type checker

+{-# LANGUAGE AllowAmbiguousTypes #-}++module Analyzer.TypeDefinitions.Class+  ( IsDeclType (..),+    IsEnumType (..),+  )+where++import Analyzer.Evaluator.EvaluationError (EvaluationError)+import Analyzer.TypeDefinitions.Type+import Data.Typeable (Typeable)++-- | Marks Haskell type as a representation of a specific Wasp declaration type.+-- This is supposed to be used on types from Wasp AST (the IR between Analyzer and Generator)+-- in order to enrich them with information on how are they to be analyzed+-- (and therefore make them part of the Wasp language).+--+-- NOTE: If this Haskell type satisfies certain requirements, the IsDeclType instance for it+-- can be automatically derived from its shape by using 'Analyzer.Evaluator.TH.makeDeclType'.+class Typeable a => IsDeclType a where+  declType :: DeclType++-- TODO: Implement declEvaluate here? We don't really need it, but that way+--   it would be consistent with IsEnumType below, and if we need it we have it.+--   dtEvaluate would then use declEvaluate.++-- | Marks Haskell type as a representation of a specific Wasp enum type.+-- Analogous to IsDeclType, but for enums.+--+-- NOTE: If this Haskell type satisfies certain requirements, the IsEnumType instance for it+-- can be automatically derived from its shape by using 'Analyzer.Evaluator.TH.makeEnumType'.+class Typeable a => IsEnumType a where+  enumType :: EnumType++  -- TODO: Elevate this function so it takes TypedExpr instead of a String?

Done

craigmc08

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentwasp-lang/wasp

feat: Implement evaluator for new type checker

+{-# LANGUAGE AllowAmbiguousTypes #-}++module Analyzer.TypeDefinitions.Class+  ( IsDeclType (..),+    IsEnumType (..),+  )+where++import Analyzer.Evaluator.EvaluationError (EvaluationError)+import Analyzer.TypeDefinitions.Type+import Data.Typeable (Typeable)++-- | Marks Haskell type as a representation of a specific Wasp declaration type.+-- This is supposed to be used on types from Wasp AST (the IR between Analyzer and Generator)+-- in order to enrich them with information on how are they to be analyzed+-- (and therefore make them part of the Wasp language).+--+-- NOTE: If this Haskell type satisfies certain requirements, the IsDeclType instance for it+-- can be automatically derived from its shape by using 'Analyzer.Evaluator.TH.makeDeclType'.+class Typeable a => IsDeclType a where+  declType :: DeclType++-- TODO: Implement declEvaluate here? We don't really need it, but that way

Done

craigmc08

comment created time in 4 days

PullRequestReviewEvent

push eventwasp-lang/wasp

Martin Sosic

commit sha 08eec6f1c77e042d94a72fd546d34bc58a611762

Added declEvaluate function.

view details

Martin Sosic

commit sha 70fc06ee15035fd9655334fc1c2b0330dc0ae31c

IsEnumType now has enumEvaluate method.

view details

push time in 4 days

startedlazamar/haskell-docs-cli

started time in 5 days

startedbitc/hs-term-emulator

started time in 5 days

push eventMartinsos/dotfiles

Martin Sosic

commit sha 86a6061bd07a9b1dd72fc435df98f4b6baf2176e

Small gitconfig update.

view details

push time in 5 days